On Mon, Mar 17, 2008 at 8:02 AM, Antonio Petrelli <[EMAIL PROTECTED]> wrote: > 2008/3/17, Greg Reddin <[EMAIL PROTECTED]>: > > > > > On Sat, Mar 15, 2008 at 10:48 AM, <[EMAIL PROTECTED]> wrote: > > > Log: > > > TILES-253 > > > Reorganized exceptions: now TilesException is a RuntimeException. > > > Created new specific exceptions. > > > > I haven't had time to fully investigate this, so I apologize if I > > misunderstand. But I'm not real comfortable with the idea of > > completely removing checked exceptions and making everything a runtime > > exception. I understand the need to support runtime exceptions and am > > not opposed to creating a TilesRuntimeException or something of the > > like, but it seems like maybe there are still parts of the API that > > might need to declare checked exceptions. > > > > Sorry if I seem rude, but I think that the choice of using only checked > exceptions was a wrong choice. If you take a look on where TilesException > (and its extended exceptions) is thrown, you may notice that, in fact, they > are all configuration exceptions (errors in xml files, problems with > instantiations, etc.). > In fact I was thinking of let all the exceptions extend a > TilesRuntimeException, but when I noticed that all the exception were, in > fact, "system" exceptions, I decided to transform TilesException into a > RuntimeException. > For example, take Hibernate, where everything may throw an unchecked > exception: this helps a lot in finding bugs. > The binary compatibility will be preserved, but the readability of the code > is really improved. > But, anyway, SVN is there also for reverting changes :-)
Not having time to examine all the cases, here's my 2 cents. If there are any exceptions that we can reasonable expect the calling code to handle and recover from, those should be checked. Otherwise, we should discourage any unnecessary/unhelpful exception catching by switching the rest to runtime exceptions. > Antonio >
