[rules-dev] Drools API improvement sugestion

[James C. Owen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081212/692f077d/attachment.html