[rules-dev] Drools API improvement sugestion

David Sinclair dsinclair at chariotsolutions.com
Fri Dec 12 13:30:04 EST 2008 

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 <greg_barton at yahoo.com> 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 <jco at kbsc.com> wrote:
>
> > From: James C. Owen <jco at kbsc.com>
> > Subject: Re: [rules-dev] Drools API improvement sugestion
> > To: "Greg Barton" <greg_barton at yahoo.com>, "Rules Dev List" <
> rules-dev at lists.jboss.org>, zoly at 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 at daxtechnologies.com> wrote:
> > >
> > >> From: Zoltan Farkas
> > <zoly at daxtechnologies.com>
> > >> Subject: RE: [rules-dev] Drools API improvement
> > sugestion
> > >> To: "Rules Dev List"
> > <rules-dev at lists.jboss.org>
> > >> 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 at lists.jboss.org
> > >> [mailto:rules-dev-bounces at 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 at lists.jboss.org
> > >>
> >       https://lists.jboss.org/mailman/listinfo/rules-dev
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> rules-dev mailing list
> > >> rules-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/rules-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > rules-dev mailing list
> > > rules-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081212/9e9a2936/attachment.html

More information about the rules-dev mailing list