Re: [rules-dev] Drools API improvement sugestion

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 <jco(a)kbsc.com&gt; wrote: > From: James C. Owen <jco(a)kbsc.com&gt; > Subject: Re: [rules-dev] Drools API improvement sugestion > To: "Greg Barton" <greg_barton(a)yahoo.com&gt;, "Rules Dev List" <rules-dev(a)lists.jboss.org&gt;, zoly(a)daxtechnologies.com > 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 >> > <zoly(a)daxtechnologies.com&gt; wrote: > >>> From: Zoltan Farkas >>> > <zoly(a)daxtechnologies.com&gt; > >>> Subject: RE: [rules-dev] Drools API improvement >>> > sugestion > >>> To: "Rules Dev List" >>> > <rules-dev(a)lists.jboss.org&gt; > >>> 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: rules-dev-bounces(a)lists.jboss.org >>> [mailto:rules-dev-bounces@lists.jboss.org] 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 >>> rules-dev(a)lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/rules-dev > >>> >>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev