Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
