> 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@daxtechnologies.com> wrote:
> >
> >> From: Zoltan Farkas
> <
zoly@daxtechnologies.com>
> >> Subject: RE: [rules-dev] Drools API improvement
> sugestion
> >> To: "Rules Dev List"
> <
rules-dev@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@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@lists.jboss.org
> >>
>
https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >>
rules-dev@lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> >
rules-dev@lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev