[rules-dev] Drools API improvement sugestion

[Zoltan Farkas]

>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
	  


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