Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Call for Votes: new name for ParseException

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Francois Beausoleil" <fbos AT users.sourceforge.net>
  • To: "John Cowan" <jcowan AT reutershealth.com>, "Elliotte Rusty Harold" <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Call for Votes: new name for ParseException
  • Date: Wed, 23 Jul 2003 11:59:59 -0400

I would beg to differ. Errors should be reserved for things which break
the whole application. When you receive an Error, we have a catastrophic
failure and we cannot continue.

If a document is malformed, the application can recover by rejecting the
document and/or asking the user to correct the document. Exceptions are
more appropriate in this case.

Hope that helps,
François

On Wed, 23 Jul 2003 11:18:50 -0400, "John Cowan"
<jcowan AT reutershealth.com> said:
> Elliotte Rusty Harold scripsit:
>
> > That's a new one to me. Where did you get that idea from?
>
> The 1.4.2 Javadoc for class Error says:
>
> # An Error is a subclass of Throwable that indicates serious problems
> # that a reasonable application should not try to catch.
>
> Similarly, the JLS says in section 11.5.2:
>
> # The class Error and its standard subclasses are exceptions from which
> # ordinary programs are not ordinarily expected to recover.
>
> JFBP is a component library I wrote where the user writes a small glue
> class to
> connect the components; you can learn to write glue classes without
> really
> knowing any Java, more or less analogous to shell programming. If the
> components are unable to connect at run time,
> the framework throws subclasses of Error to indicate what's wrong.
>
> > unusualfor a Java program to throw an Error. Errors almost always
> > indicate a failure in the VM that can rarely be predicted or handled,
> > e.g. OutOfMemoryError or ClassFormatError. Very few user programs
> > should ever throw or even handle errors. The contract of error is not
> > that the programmer has blundered. It's that the VM has failed in
> > some way.
>
> Not necessarily. Loading the J2SE 1.4.2 class hierarchy at
> http://java.sun.com/j2se/1.4.2/docs/api/overview-tree.html (takes a
> looong
> time to load even over a fast wire), I see the following descendants of
> java.lang.Error that don't have those semantics:
>
> java.lang.AssertionError (this is all about programmer faults)
> java.nio.charset.CoderMalfunctionError (this indicates an exception in a
> charset decoder or encoder, which is supposed to be "safe code")
> javax.xml.parsers.FactoryConfigurationError (the parser factory given in
> the
> system properties doesn't exist or is broken)
> javax.xml.transform.TransformerFactoryConfigurationError (same story, but
> for
> a transformation factory)
>
> Indeed, it seems to me that the subclasses of nu.xom.XMLException are all
> essentially very like assertion failures, which throw Errors as shown
> above.
>
> --
> Is a chair finely made tragic or comic? Is the John Cowan
> portrait of Mona Lisa good if I desire to see
> jcowan AT reutershealth.com
> it? Is the bust of Sir Philip Crampton lyrical,
> www.ccil.org/~cowan
> epical or dramatic? If a man hacking in fury
> www.reutershealth.com
> at a block of wood make there an image of a cow,
> is that image a work of art? If not, why not? --Stephen
> Dedalus
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest
>
Developer of Java Gui Builder
http://jgb.sourceforge.net/




Archive powered by MHonArc 2.6.24.

Top of Page