Re: SAXException, checked, buy why?
Alan Gutierrez wrote: >>> 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. > > > No. I think that means a lot of Object. > > Attaching a map to the error event? The fact that you are adding certain methods with a specific signature already defines dependencies, even if you use Object everywhere. Using an abstract class is more open, IMO. It would serve as what you would call an opaque pointer in other languages. >>> 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. > > > You, think, then that this event-like model, with an observer is > the way to go? If you don't want to modify the SAX API, then yes. Karl
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format