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
