Greg Barton 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.
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.

Mark
--- On Fri, 12/12/08, James C. Owen <jco@kbsc.com> wrote:

  
From: James C. Owen <jco@kbsc.com>
Subject: Re: [rules-dev] Drools API improvement sugestion
To: "Greg Barton" <greg_barton@yahoo.com>, "Rules Dev List" <rules-dev@lists.jboss.org>, zoly@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@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