Alan Gutierrez wrote:

>>>   The class in final because a SAX error is really just a wrapper
>>>   for a real, application error. No message either. That is found
>>>   in the real cause. Eh?
> 
> 
>>If you made your class abstract, then your content handler and application
>>could agree on some shared way of exchanging information (through a subclass
>>known to both of them) that is best suited to the problem at hand, without
>>involving the API too much.
> 
> 
>>Did you say "Eh?" to point out my Canadian domain name?
>>Well, its true, I live there, but if you heard my accent ... ;-)
> 
> 
>     No. It was just to solicit a response.
> 
>     Why Canadians are to touchy a boot their accents?

I am not touchy at all about it, I just find it amusing.
I don't think Canadians have an accent worth mentioning.
Btw, I am not a Canadian ...

>     I think the API sticks it's nose in. I think API provides a
>     conduit for XML message events coming in, and it needs to
>     provide a conduit for error events going, er, where ever.

Yes, a conduit, but it should not care about what goes through that conduit.
This would create unnecessary dependencies.

> 
>     Did I already state that I see errors as simply more events? I
>     do for now, at lest. Within handling, an error is an event, to
>     be handled, and is thrown as a last resort.

There are always multiple view points.
In an event based API it is natural to see errors as events.
The design challenge often is to come up with a solution
that looks reasonable from different view points.

Karl