[digester] using digester's exceptions

[Erik Price <ep...@ptc.com>]

Does it go against the intent/contract of the Digester package to use 
some of its classes out of the context in which they were designed?  I 
want to raise an exception if my field is still null after trying to set 
the field with a Digester instance, but I'm wondering if this is really 
appropriate:

public abstract class AbstractReport implements Report {
     private Criteria criteria;

     /**
      * Generates a Report from information in the passed-in file.
      */
     public AbstractReport(File file) throws IOException {
         Digester digester = new Digester();
         digester.push(this);
         digester.addObjectCreate("criteria",
                                  "com.erikprice.oatmeal.Criteria");
         digester.addSetNext("criteria", "setCriteria");
         // other rules go here
         digester.parse(file);

         if (this.criteria == null) {
------->    throw new XmlLoadException("criteria field not registered");
         }
         // do other processing using this.criteria
     }
}



Thanks,

Erik

Re: [digester] using digester's exceptions

[Dave Newton <da...@solaraccess.com>]

On Tue, 2003-03-11 at 17:52, robert burrell donkin wrote:
> On Tuesday, March 11, 2003, at 10:11 PM, Erik Price wrote:
> > Thanks Robert.  My concern arose from the fact that, when I investigated 
> > the classes that extend java.lang.Exception, there are a ton of 
> > CORBA-specific or JNDI-specific (etc) Exceptions and I wondered if we're 
> > all supposed to make custom exceptions like this all the time.
> this is a concern - but i didn't really want to get into the issue of the 
> 'right' exception handling strategy. there are different schools of 
> thought about the right way to do exception handling. IMHO this issue can 
> get a little religious.

Reverend Dave says: I hate relying on other people's classes if they
might change at any time. Probably won't happen in this case, but for
maximum reusability (java, after all ;) I almost always create my own
exception classes.

As a pathological example, what if you wanted to use the exact same code
using somebody else's Digester thus losing access to the
commons-digester XmlLoadException? 

Or if you were throwing it from deeper within your code from a
generalized method that neither would nor should know anything about a
Digester at all?

Again, in this case I'm sure it doesn't matter, so I'll take off the
funny hat now.

Dave

Re: [digester] using digester's exceptions

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Tuesday, March 11, 2003, at 10:11 PM, Erik Price wrote:

> robert burrell donkin wrote:
>> hi erik
>> my short answer is: digester is open source - use it any way you want!
>> my longer answer is: i can't think of any major issues that you'll have 
>> using XmlLoadException in that way. if you want to follow sun's javadoc 
>> guidelines you might want to add a @throws tag.
>
> Thanks Robert.  My concern arose from the fact that, when I investigated 
> the classes that extend java.lang.Exception, there are a ton of 
> CORBA-specific or JNDI-specific (etc) Exceptions and I wondered if we're 
> all supposed to make custom exceptions like this all the time.

this is a concern - but i didn't really want to get into the issue of the 
'right' exception handling strategy. there are different schools of 
thought about the right way to do exception handling. IMHO this issue can 
get a little religious.

- robert

Re: [digester] using digester's exceptions

[Erik Price <ep...@ptc.com>]

robert burrell donkin wrote:
> hi erik
> 
> my short answer is: digester is open source - use it any way you want!
> 
> my longer answer is: i can't think of any major issues that you'll have 
> using XmlLoadException in that way. if you want to follow sun's javadoc 
> guidelines you might want to add a @throws tag.

Thanks Robert.  My concern arose from the fact that, when I investigated 
the classes that extend java.lang.Exception, there are a ton of 
CORBA-specific or JNDI-specific (etc) Exceptions and I wondered if we're 
all supposed to make custom exceptions like this all the time. 
(Actually I should probably just use "assert", however the deployment 
platform will probably be a 1.2 JRE.)  But you're right, 
XmlLoadException is open source and conveys exactly the message I'm 
thinking of, so I can't think of why this would be a problem either.

I forgot to add the @throws tag, thanks!


Erik

Re: [digester] using digester's exceptions

[robert burrell donkin <ro...@blueyonder.co.uk>]

hi erik

my short answer is: digester is open source - use it any way you want!

my longer answer is: i can't think of any major issues that you'll have 
using XmlLoadException in that way. if you want to follow sun's javadoc 
guidelines you might want to add a @throws tag.

- robert

On Tuesday, March 11, 2003, at 06:38 PM, Erik Price wrote:

> Does it go against the intent/contract of the Digester package to use 
> some of its classes out of the context in which they were designed?  I 
> want to raise an exception if my field is still null after trying to set 
> the field with a Digester instance, but I'm wondering if this is really 
> appropriate:
>
> public abstract class AbstractReport implements Report {
>     private Criteria criteria;
>
>     /**
>      * Generates a Report from information in the passed-in file.
>      */
>     public AbstractReport(File file) throws IOException {
>         Digester digester = new Digester();
>         digester.push(this);
>         digester.addObjectCreate("criteria",
>                                  "com.erikprice.oatmeal.Criteria");
>         digester.addSetNext("criteria", "setCriteria");
>         // other rules go here
>         digester.parse(file);
>
>         if (this.criteria == null) {
> ------->    throw new XmlLoadException("criteria field not registered");
>         }
>         // do other processing using this.criteria
>     }
> }
>
>
>
> Thanks,
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>