<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Greg Barton wrote:
<blockquote cite="mid:984234.65484.qm@web81503.mail.mud.yahoo.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
The general belief is that actually in practice few exceptions can be
truly recovered, if they can't be recovered then you might as well let
them bubble up to the root of the program for logging before it exits.
This is why many people catch the static exception wrap as runtime and
then re-throw - this is what we already do in the innards of drools all
over the place, turning possible static exceptions into runtime ones to
bubble up to the user.<br>
<br>
Mark<br>
<blockquote cite="mid:984234.65484.qm@web81503.mail.mud.yahoo.com"
type="cite">
<pre wrap="">
--- On Fri, 12/12/08, James C. Owen <a class="moz-txt-link-rfc2396E" href="mailto:jco@kbsc.com"><jco@kbsc.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">From: James C. Owen <a class="moz-txt-link-rfc2396E" href="mailto:jco@kbsc.com"><jco@kbsc.com></a>
Subject: Re: [rules-dev] Drools API improvement sugestion
To: "Greg Barton" <a class="moz-txt-link-rfc2396E" href="mailto:greg_barton@yahoo.com"><greg_barton@yahoo.com></a>, "Rules Dev List" <a class="moz-txt-link-rfc2396E" href="mailto:rules-dev@lists.jboss.org"><rules-dev@lists.jboss.org></a>, <a class="moz-txt-link-abbreviated" href="mailto:zoly@daxtechnologies.com">zoly@daxtechnologies.com</a>
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
<a class="moz-txt-link-freetext" href="http://www.kbsc.com">http://www.kbsc.com</a>
Founder October Rules Fest
<a class="moz-txt-link-freetext" href="http://www.OctoberRulesFest.org">http://www.OctoberRulesFest.org</a>
Blogs:
<a class="moz-txt-link-freetext" href="http://JavaRules.blogspot.com">http://JavaRules.blogspot.com</a> [Java-Oriented Rulebased
Systems]
<a class="moz-txt-link-freetext" href="http://ORF2009.blogspot.com">http://ORF2009.blogspot.com</a> [October Rules Fest]
<a class="moz-txt-link-freetext" href="http://exscg.blogspot.com/">http://exscg.blogspot.com/</a> [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
<a class="moz-txt-link-freetext" href="http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html">http://www-tech.mit.edu/Shakespeare/hamlet/hamlet.1.3.html</a>
On Dec 12, 2008, at 10:30 AM, Greg Barton wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I vote for runtime exception. That gives you the
</pre>
</blockquote>
<pre wrap="">option of catching
</pre>
<blockquote type="cite">
<pre wrap="">it or not. Just from experience I can't tell you
</pre>
</blockquote>
<pre wrap="">how nice it was
</pre>
<blockquote type="cite">
<pre wrap="">when HibernateException went from a checked to an
</pre>
</blockquote>
<pre wrap="">unchecked exception.
</pre>
<blockquote type="cite">
<pre wrap="">That being said, the API methods that can throw it
</pre>
</blockquote>
<pre wrap="">should still
</pre>
<blockquote type="cite">
<pre wrap="">declare it in the throws clause, even if it's a
</pre>
</blockquote>
<pre wrap="">runtime exception.
</pre>
<blockquote type="cite">
<pre wrap="">That helps IDEs like Eclipse wrap method calls in the
</pre>
</blockquote>
<pre wrap="">right try/
</pre>
<blockquote type="cite">
<pre wrap="">catch blocks when generating code. (See the
</pre>
</blockquote>
<pre wrap="">"Source->Surround With-
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">try/catch block" menu option)
</pre>
</blockquote>
<pre wrap="">--- On Fri, 12/12/08, Zoltan Farkas
</pre>
</blockquote>
<pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:zoly@daxtechnologies.com"><zoly@daxtechnologies.com></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">From: Zoltan Farkas
</pre>
</blockquote>
</blockquote>
<pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:zoly@daxtechnologies.com"><zoly@daxtechnologies.com></a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Subject: RE: [rules-dev] Drools API improvement
</pre>
</blockquote>
</blockquote>
<pre wrap="">sugestion
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">To: "Rules Dev List"
</pre>
</blockquote>
</blockquote>
<pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:rules-dev@lists.jboss.org"><rules-dev@lists.jboss.org></a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Date: Friday, December 12, 2008, 10:10 AM
</pre>
<blockquote type="cite">
<pre wrap="">From my point of view as a developer who
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">writes code
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">against the api,
I have to handle to case of a Resource not being
</pre>
</blockquote>
</blockquote>
<pre wrap="">there, or
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">being
invalid/corupt... theese are casses that I need to
</pre>
</blockquote>
</blockquote>
<pre wrap="">recover
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">from in my
code...
and I have no way of knowing what do I need to
</pre>
</blockquote>
</blockquote>
<pre wrap="">catch and
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">where, without
first writing the code, run tests against it, and
</pre>
</blockquote>
</blockquote>
<pre wrap="">examine
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">stack traces.
I find this quite inefficient...
If you google for ResourceNotFoundException, you
</pre>
</blockquote>
</blockquote>
<pre wrap="">will find
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">out that
there is quite a few APIs out there that implement
</pre>
</blockquote>
</blockquote>
<pre wrap="">it.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">There is other
apis that have InvalidResourceException... or
javx.resource.ResourceException
My preference would be toward catched Exceptions
</pre>
</blockquote>
</blockquote>
<pre wrap="">in this
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">case.
--zoly
________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:rules-dev-bounces@lists.jboss.org">rules-dev-bounces@lists.jboss.org</a>
[<a class="moz-txt-link-freetext" href="mailto:rules-dev-bounces@lists.jboss.org">mailto:rules-dev-bounces@lists.jboss.org</a>] On
</pre>
</blockquote>
</blockquote>
<pre wrap="">Behalf Of
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Mark Proctor
Sent: Thursday, December 11, 2008 8:04 PM
To: Rules Dev List
Subject: Re: [rules-dev] Drools API improvement
</pre>
</blockquote>
</blockquote>
<pre wrap="">sugestion
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
Zoltan Farkas wrote:
Based on current implementation, the following
</pre>
</blockquote>
</blockquote>
<pre wrap="">methods I
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">think
should throw a exception, something like:
ResourceNotFoundException
do you want this as runtime or catched exception?
</pre>
</blockquote>
</blockquote>
<pre wrap="">At the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">moment we are
trying to avoid catched exceptions.
Mark
</pre>
</blockquote>
</blockquote>
<pre wrap=""> org.drools.compiler.PackageBuilder.addKnowledgeResource()
</pre>
<pre wrap=""> org.drools.builder.impl.KnowledgeBuilderImpl.add()
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
another option might be to verify the validity of
</pre>
</blockquote>
</blockquote>
<pre wrap="">a
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Resource
object at creation time and make ResourceFactory
</pre>
</blockquote>
</blockquote>
<pre wrap="">factory
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">methods throw
ResourceNotFoundException.
I believe the case of a "not found
</pre>
</blockquote>
</blockquote>
<pre wrap="">resource" the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">user of the api
should be "ecouraged" to handle.
Another case that might be needed to be handled
</pre>
</blockquote>
</blockquote>
<pre wrap="">could be
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">InvalidResource?
Let me know what you guys think
Regards
--zoly
________________________________
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""> <a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>