[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
To: "Karl Waclawek" <karl@waclawek.net>
Cc: <xml-dev@lists.xml.org>; <sax-devel@lists.sourceforge.net>
Sent: Friday, February 27, 2004 7:30 PM
> At 6:40 PM -0500 2/27/04, Karl Waclawek wrote:
>
> >I admit I am not a native speaker, but IMO the wording above
> >would not contradict the behaviour of an exception stopping
> >the parser cold. Exceptions are normally thought of as
> >the "exceptional" case, and documenting the behaviour of an
> >implementation does usually not imply that it will behave
> >the same when an exception is thrown.
> >
>
> A very good point. However, I think the sort of exception you're
> describing is only a truly exceptional exception such as an I/O error
> like a broken socket or an out of memory condition. I'm not sure a
> malformed document qualifies as exceptional in this context.
I agree. I rather thought of exceptions thrown in the call-backs,
based on how the application deals with the information it receives.
> There's
> no reason, after all, the parse method has to throw an exception to
> indicate malformedness. It could easily have returned a boolean
> indicating whether or not the document was well-formed. Not that I'm
> suggesting such a change at this late date, of course. I just want to
> point out that there are other ways to design such an API that don't
> rely on exceptions.
That would be more along my line of thinking anyway ...
> In practice I encounter malformed documents far
> more often than I/O errors, out of memory errors, and similar
> problems. They just don't feel that exceptional to me.
Absolutely.
Karl
|
