Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] Exception hierarchy

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] Exception hierarchy
  • Date: Sun, 18 Jan 2004 10:19:55 -0500

Last night I started looking at XOM's exception hierarchy, and decided it might benefit form some rejiggering, though I seem to be changing my mind every hour or so about exactly how to reorganize it, so commennts are appreciated.

The specific incentive was the desire to add extra information to four exceptions: IllegalDataException, IllegalNameException, IllegalTargetException, and MalformedURIException. Specifically, I wanted to give each of them a method that returned the dpecific illegal string, the malformed URI, the illegal name, etc. This seems useful for debugging and error reporting, and should have negligible if any impact in the non-exceptional case.

However, in the process of doing this it became tricky because of inheritance issues. For instance, getTarget and setTarget seem like obvious methods for IllegalTargetException. However, that's a subclass of IllegalDataException, so what do I to with getData and setData inherited from IllegalDataException?

I've also noticed problems with issues between IllegalNameException and NamespaceException. It's not always obvious which one is thrown when. This has been a consistent and occasional thorn in my side for the last year. It's not a big issue, but I often find myself surprised by an IllegalNameException when I expect a NamespaceException and vice versa, and that isn't good. Perhaps the problem here is that NamespaceException is used for two different things: namespace illegal content such as a prefix that contains a colon and namespace conflicts such as an atttribute that maps a prefix to a different URI than another attribute on the same element does.

Thus my current thinking is to rearrange the exception hierarchy like this:


WellformednessException
|
+--NamespaceConflictException
|
+--IllegalDataException
|
+--IllegalContentException
|
+--MalformedURIException
|
+--IllegalNameException
|
+--IllegalTargetException
|
+--IllegalNamespaceException


This would mean IllegalDataException becomes a common superclass for pretty much anything that could go wrong as a result of verification issues. What was IllegalDataException in the past would now be IllegalContentException. IllegalDataException would have setData and getData methods that return the specific illegal string. These methods would of course be inherited by all the subclasses.

One of the things I'm least certain of is whether IllegalTargetException and IllegalNamespaceException should be direct subclasses of IllegalNameException or of IllegalDataException.

Thoughts? Comments? Does anyone have a better idea? This is very much up in the air, but I would like to resolve it soon, since I'm very close to a "last Call" on the API.

--

Elliotte Rusty Harold
elharo AT metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA




Archive powered by MHonArc 2.6.24.

Top of Page