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
