Totally agree. I often turned checked exceptions into unchecked ones for core JDK classes. For example, MethodNotFoundException. That is totally programmer's fault.
On Fri, Dec 12, 2008 at 12:53 PM, Greg Barton <[email protected]> wrote: > I dunno, man. Do you catch every NullPointerException or > ArrayIndexOutOfBoundsException you could? I'm thinking not. > > Yes, exceptions should be caught whenever possible, but forcing that on the > programmer too much can lead to this kind of pattern: > > try { > ... > } catch(OverusedAndThusAnnoyingCheckedException e) {} > > This is CONCENTRATED EVIL. :) See "Item 65: Don't ignore exceptions" in > Josh Bloch's "Effective Java." Heck just see all of chapter 9. :) > > In fact, this leads me to Bloch's "Item 58: Use checked exceptions for > recoverable conditions and runtime exceptions for programming errors." It > strikes me that a resource being missing can often be a programming error > (fat fingered resource name) but can also be a recoverable communication > error. (remote storage unavailable) I still lean towards an unchecked > exception, though, because more often than not the resources in question > will be loaded from jars in the classpath, and failure to load them will me > mostly due to programmer error. > > --- On Fri, 12/12/08, James C. Owen <[email protected]> wrote: > > > From: James C. Owen <[email protected]> > > Subject: Re: [rules-dev] Drools API improvement sugestion > > To: "Greg Barton" <[email protected]>, "Rules Dev List" < > [email protected]>, [email protected] > > Date: Friday, December 12, 2008, 11:15 AM > > Greetings: > > > > Not too often do I get personally involved in Java/J2EE > > disputes among > > those who are virtually experts at this game. However, > > exceptions is > > one of my pet peeves. NOT catching an exception shows a > > bit of > > disregard for the integrity of the product itself and, > > IMHO, > > everything should be in a try / catch block such that the > > exception is > > NOT caught only in trivial circumstances. (And if it's > > so trivial > > that it doesn't need a try/catch block, is it necessary > > at all?) > > > > As an old C programmer (yes, there are still a few of us > > around) if we > > thought that we were really, really good programmers we > > would run > > "lint" on our program before sending it to QA. > > And QA always ran > > "lint" just for the fun of showing up our poor > > programming. It was > > usually an humbling experience. Catching all of the > > exceptions during > > testing should be required. Catching all of the exceptions > > during run > > time is debatable. I would think that NOT catching > > exceptions is what > > makes for run time problems that could have been caught > > during compile/ > > design time. > > > > The final question is WHAT to do with a caught exception? > > This is > > where experience shows up and with some you can just toss > > an error > > statement in a log somewhere with a warning. Others > > require an error > > routine and stopping the program. Then that becomes a > > matter of > > judgement. Catch and release? Nahhh... I only fish to > > eat, not for > > sport. :-) > > > > Just two cents. > > > > SDG > > James Owen > > Senior Consultant / Architect > > 817.656.4553 office > > 214.684.5272 cell > > Founder KnowledgeBased Systems Corporation > > http://www.kbsc.com > > Founder October Rules Fest > > http://www.OctoberRulesFest.org > > Blogs: > > http://JavaRules.blogspot.com [Java-Oriented Rulebased > > Systems] > > http://ORF2009.blogspot.com [October Rules Fest] > > http://exscg.blogspot.com/ [Expert Systems Consulting > > Group] > > "This above all: to thine own self be true, > > And it must follow, as the night the day, > > Thou canst not then be false to any man." > > Hamlet, Act 1, Scene III > > http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html > > > > > > > > > > On Dec 12, 2008, at 10:30 AM, Greg Barton wrote: > > > > > I vote for runtime exception. That gives you the > > option of catching > > > it or not. Just from experience I can't tell you > > how nice it was > > > when HibernateException went from a checked to an > > unchecked exception. > > > > > > That being said, the API methods that can throw it > > should still > > > declare it in the throws clause, even if it's a > > runtime exception. > > > That helps IDEs like Eclipse wrap method calls in the > > right try/ > > > catch blocks when generating code. (See the > > "Source->Surround With- > > > >try/catch block" menu option) > > > > > > --- On Fri, 12/12/08, Zoltan Farkas > > <[email protected]> wrote: > > > > > >> From: Zoltan Farkas > > <[email protected]> > > >> Subject: RE: [rules-dev] Drools API improvement > > sugestion > > >> To: "Rules Dev List" > > <[email protected]> > > >> Date: Friday, December 12, 2008, 10:10 AM > > >>> From my point of view as a developer who > > writes code > > >> against the api, > > >> I have to handle to case of a Resource not being > > there, or > > >> being > > >> invalid/corupt... theese are casses that I need to > > recover > > >> from in my > > >> code... > > >> and I have no way of knowing what do I need to > > catch and > > >> where, without > > >> first writing the code, run tests against it, and > > examine > > >> stack traces. > > >> I find this quite inefficient... > > >> > > >> If you google for ResourceNotFoundException, you > > will find > > >> out that > > >> there is quite a few APIs out there that implement > > it. > > >> There is other > > >> apis that have InvalidResourceException... or > > >> javx.resource.ResourceException > > >> > > >> My preference would be toward catched Exceptions > > in this > > >> case. > > >> > > >> --zoly > > >> > > >> > > >> ________________________________ > > >> > > >> From: [email protected] > > >> [mailto:[email protected]] On > > Behalf Of > > >> Mark Proctor > > >> Sent: Thursday, December 11, 2008 8:04 PM > > >> To: Rules Dev List > > >> Subject: Re: [rules-dev] Drools API improvement > > sugestion > > >> > > >> > > >> Zoltan Farkas wrote: > > >> > > >> Based on current implementation, the following > > methods I > > >> think > > >> should throw a exception, something like: > > >> ResourceNotFoundException > > >> > > >> do you want this as runtime or catched exception? > > At the > > >> moment we are > > >> trying to avoid catched exceptions. > > >> > > >> Mark > > >> > > >> > > >> > > >> > > org.drools.compiler.PackageBuilder.addKnowledgeResource() > > >> > > org.drools.builder.impl.KnowledgeBuilderImpl.add() > > >> > > >> another option might be to verify the validity of > > a > > >> Resource > > >> object at creation time and make ResourceFactory > > factory > > >> methods throw > > >> ResourceNotFoundException. > > >> > > >> I believe the case of a "not found > > resource" the > > >> user of the api > > >> should be "ecouraged" to handle. > > >> > > >> Another case that might be needed to be handled > > could be > > >> InvalidResource? > > >> > > >> Let me know what you guys think > > >> > > >> Regards > > >> > > >> --zoly > > >> > > >> ________________________________ > > >> > > >> > > >> _______________________________________________ > > >> rules-dev mailing list > > >> [email protected] > > >> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > >> > > >> > > >> > > >> _______________________________________________ > > >> rules-dev mailing list > > >> [email protected] > > >> https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > > > > > > _______________________________________________ > > > rules-dev mailing list > > > [email protected] > > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
