Re: [xml-dev] SAXException, checked, buy why?

[Alan Gutierrez <alan-xml-dev@engrm.com>]

* Karl Waclawek <karl@waclawek.net> [2005-01-03 19:23]:
> 
> 
> Alan Gutierrez wrote:
> 
> That is how I see it too.  When I looked at renaming the
> ParseError class today, I realized that all its members are geared
> towards parse errors (PublicId, SystemId, Line/ColumnNumber,
> etc.), just like the SAXParseException in Java.  This makes
> renaming rather insufficient.

> All those parse error specific members could probably be collected
> into one optional member of type ILocator (Locator in Java).  That
> way - after renaming it to SAXError - it would become more usable
> for general error processing.  But that means breaking more and
> more with the original Java.

    I've yet to sort out how put the error information into the mix. 

> >>As an example for another possible approach, one could have
> >>defined all handlers to accept a "Status" object as additional
> >>parameter (based on some abstract class definition).  Each handler
> >>in the chain could inspect and modify this object, allowing
> >>information to pass up and down.  The application could register a
> >>concrete subclass instance of that Status class with the event
> >>generator, to provide for custom processing of errors.

> >    I am working with a bevy resuable handlers that I reuse through
> >    object composition. In any SAX content handler in a content
> >    handler chain, I've got dozens of objects decorating and
> >    delegating.

> >    Its not one monolithic SAX content handler, but a composition of
> >    SAX strategies.

> Obviously that means exchange of information between them
> becomes important.

    Yes.
    
    The concept is that a stack of Strategy objects is built. One
    Strategy can push a new Strategy on to a stack to handle, er,
    sub-tree, (is that kosher?), and it pops autmoatically on the
    way back. There's a number of ways to communicate.

    I didn't think of it, until pecking this out right now, but...

    There are "stock" Strategy objects, SAXInterceptor,
    TraxInterceptor, W3CDOMIntercepor.

    A user defined Strategy might delegate a sub-tree to a "stock"
    Strategy, the stock Strategy may a set of recoverable
    exceptional conditions, and the user defined Strategy as the
    client, should handle those conditions. 

    So, in my model, this same event exception design challenge
    present themselves. It boils down to deep exceptions, through a
    generic messaging conduit, or in this last case exceptions when
    the catcher isn't in the thrower's call stack.

    (I'm looking at event UIs, like Swing, and reflection, to see
        how they handle this design challenge.)

> >    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 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.

    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.

> >    I've decided to forgo checked exceptions. (I've had my
> >    awakening.) I'll have that debate with anyone, if they'd like,
> >    so's to learn something. I know its a common an trollish debate,
> >    so I've avoided it in the past. I will gladly read any
> >    references on the state of that debate.

> This is what Anders Hejlsberg (C# designer) has to say:
> http://www.artima.com/intv/handcuffs.html
    
    He's right.
    
    This is an area of dogma, and it gets in the way of practice.
    When you talk about exceptoins in Java, you end up having the
    checked, unchecked exception debate all over again. It is at
    least a necessary formality, establishing your checked versus
    unchecked opinion, so you can discuss anything else.

    Then the Java communities rarely go on to discuss anything else.

    When I read about exceptions in C++, they discuss the different
    levels of exception saftey and exception garuntees. 

    They really are a distraction, and in themselves, don't solve
    anything.
    
--
Alan Gutierrez - alan@engrm.com