<!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:866115.91060.qm@web81505.mail.mud.yahoo.com"
 type="cite">
  <pre wrap="">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.
  </pre>
</blockquote>
Yes there has been a general backlash against forced static exceptions,
especially say if you know the Resource is from a byte[] or String.<br>
<blockquote cite="mid:866115.91060.qm@web81505.mail.mud.yahoo.com"
 type="cite">
  <pre wrap="">
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. </pre>
</blockquote>
I was just planning to let people do null checks, but I can do this
instead - what do people prefer?<br>
<blockquote cite="mid:866115.91060.qm@web81505.mail.mud.yahoo.com"
 type="cite">
  <pre wrap=""> That helps IDEs like Eclipse wrap method calls in the right try/catch blocks when generating code.  (See the "Source-&gt;Surround With-&gt;try/catch block" menu option)

--- On Fri, 12/12/08, Zoltan Farkas <a class="moz-txt-link-rfc2396E" href="mailto:zoly@daxtechnologies.com">&lt;zoly@daxtechnologies.com&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">From: Zoltan Farkas <a class="moz-txt-link-rfc2396E" href="mailto:zoly@daxtechnologies.com">&lt;zoly@daxtechnologies.com&gt;</a>
Subject: RE: [rules-dev] Drools API improvement sugestion
To: "Rules Dev List" <a class="moz-txt-link-rfc2396E" href="mailto:rules-dev@lists.jboss.org">&lt;rules-dev@lists.jboss.org&gt;</a>
Date: Friday, December 12, 2008, 10:10 AM
&gt;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: <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 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
        <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>
          


_______________________________________________
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>
<br>
</body>
</html>