[XOM-interest] Exception hierarchy
Elliotte Rusty Harold
elharo at metalab.unc.edu
Sun Jan 18 10:19:55 EST 2004
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
More information about the XOM-interest
mailing list