Alan Gutierrez wrote:

>>Actually, in SAX for .NET we have decided to pass a non-ecxeption
>>class to the error handlers, but we are still calling it ParseError
>>- so maybe we should rename it to SAXError, to be more generic.
> 
> 
>     Naming is important.
>     
>     Thanks for this message. This is, for me, a very productive
>     discussion.
> 
>     What you're saying, is that in .NET, you didn't bother with an
>     exception. This is in line with my thinking.
>     
>     I'd like to treat the SAXError as a container and structure that
>     contains the necessary information to recover from the
>     exceptional situation. That it is also an Error, means that
>     there's a ready object for throwing, one with a correct strack
>     trace.

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.

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

>     I'd planned on using the event handler below, as described.
> 
>     public interface SAXCassandra {
>         public void error(SAXError saxError);
>     }
> 
>     The SAXError, although it will be an unchecked exception class,
>     will also provide context information.
>     
>     It will be like the status object in your .NET API. There will
>     be an added benfit of being something that the error handler can
>     throw if things don't work out.
> 
>     public class BarFooCassandara {
>         public void error(SAXError saxError) {
>             try {
> 
>                 throw error.getCause();
> 
>             } catch (FileNotFoundException e) {
> 
>                 // Perhaps providing parse state is overexposure.
> 
>                 // I've wondered why FileNotFoundException didn't
>                 // have a getFile() method since that would be what
>                 // we need here.
> 
>                 String fileName = error.getElement() // (Not really SAX.)
>                                        .getAttributes()
>                                        .getValue("file-name");
> 
>                 if (!BarFileUtils.touch(new File(fileName))) {
>                     // Throw SAXError since it's unchecked.
>                     throw saxError;
>                 }
> 
>                 // Otherwise, we are fine. Work with touched file.
>             } catch (FooResourceError e) {
>                 if (!FooManager.freeUpSomeFoos()) {
> 
>                     // Wrap this in an exception type that the
>                     // process initiator expects to catch.
> 
>                     throw new BarFooError(e);
>                 }
>             } catch (Throwable e) {
>                 // If the contianed exception is unchecked, throw
>                 // that, otherwise, throw the saxError.
>                 throw saxError.asUnchecked();
>             }
>         }
>     }
> 
>     The SAXError class now looks like:
> 
>     public final class SAXError extends Error {
>         public SAXError(Throwable cause) {
>             super("Error in SAX.", cause);
>         }
> 
>         public Element  getElement() { }
>         public Object   getErrorObject() { }    // This.
>         public Map      getErrorInfo() { }      // Even more Perlish.
>     }
> 
>     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 ... ;-)

>     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

Karl