Re: [Sax-devel] Re: SAX exception IDs
Brought to you by:
dmegginson
From: David B. <da...@pa...> - 2002-04-22 15:47:38
|
> > They can be used in a non-SAX setting already, so long as that > > setting accomodates URIs as an ID scheme. The base URI ought > > never to be relevant except in terms of uniqueness. > > That is true enough-- but with the "/sax/" portion of the URI it seems to > suggest that the error identifier has some specific SAX context. It does, in > that it is being thrown assumably by a SAX parser. All the same if some day > far in the future a reusable error interface were invented (XAE? XML API for > Errors) then having a generic cross-API error ID might be useful. I think URIs are generic enough ... :) > > When I've dealt with similar situations before, it's either been resolved > > strictly in terms of simplicity, or by having an error stack mechanism > > that more or less resembles the way a SAXException exposes a root > > cause (or JDK 1.4 now does for java.lang.Exception). > > Hmm... yeah I could see how that might work. Would there be a fatalError > stack? I initially thought that it might be too much information-- (both for > the implementer and the user) and SAX is supposed to be the "Simple API" so > in that sense it might be bad. Both "error" and "stack" would be generic notions here. Exception objects always indicate some kind of "error" (or warning), and one way to implement "stack" is as a linked list (in this case through the root cause exception objects). Java doesn't need the kind of hairy infrastructure for such things that a C or C++ application would (or Delphi?), and so SAX doesn't need any changes whatsoever. It'd just be a policy for how to use existing environment mechanisms. > But if the docs were worded such that the > getExternalIds() may return multiple ids or the "most specific applicable > rule" only, then it could still be simple. In all honesty, I think that parsers returning more than one ID would be about as uncommon as applications bothering to use more than the first one. Most implementors really can't pay much attention to fault handling ... more's the pity, but it's actually hard enough to do a good job even with just a single good indicator of what went wrong. - Dave |