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

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

* Uche Ogbuji <uche.ogbuji@fourthought.com> [2005-01-03 00:55]:
> On Sun, 2005-01-02 at 21:15 -0500, Alan Gutierrez wrote:
> > * Uche Ogbuji <uche.ogbuji@fourthought.com> [2005-01-02 20:33]:
> > 
> > > On Sun, 2005-01-02 at 19:46 -0500, Alan Gutierrez wrote:
> > 
> >         Asking: "How do you provide the fellow who invokes the event
> >         conduit with a means to pitch an exception that they will
> >         know to catch?" of a Python programmer is begging for flames.

> Sorry.  I peeked here.  Surely you didn't construe my last
> response as a flame, right?  Just an honest quest for
> clarification.

    No. :^) Not at all.
    
    The problem stuck me as a Java checked/unchecked problem. It's
    not entirely, but if you solve the handle in the handler problem
    you solve this. With Java you still have to pussy-foot around
    the method signatures.
    
    So, there's an opening for Java mockery. A flame is something
    harsher I suppose.

> >     How do you provide the fellow who invokes the event conduit with
> >     a means to intercept exceptions at the event handler?
> >     
> >     Say I've a content handler that likes to open files. The action
> >     to take when a file is not found could be to skip it an move on,
> >     or it could be that the file can be fabricated real quick, or it
> >     could be that processing has to abort via an exception.
> >     
> >     This is an application descision. How does the application
> >     developer configure the content handler so that the exceptional
> >     condition is handled during the event?
> 
> Well, my Java-Fu is decent enough to know that this is really just not
> an option in Java, but I'll go on, since I think I understand you'd be
> interested even in a non-Java answer:

> MyHandler(xml.sax.ContentHandler):
>     #Following method is the initializer (like a constructor)
>     def __init__(self, exceptions_to_ignore, exceptions_to_pass_on,
>                  exceptions_to_log):
>         self.exceptions_to_ignore = exceptions_to_ignore
>         self.exceptions_to_pass_on = exceptions_to_pass_on
>         self.exceptions_to_log = exceptions_to_log
>         self.count = 0
> 
>     def characters(self, text):
>         #Crazy example: put each text chunk into a 
>         try:
>             #May raise IOError
>             f = open(str(self.count) + '.txt')
>             f.write(text.encode('utf-8'))
>             #May raise IndexErrors for small strings
>             f.write(text[10])  #May raise 
>             #May raise UnicodeEncodeError if text contains 
>             #Characters above ASCII range (U+127)
>             f.write(text.encode('ascii'))
>             count += 1
>         except self.exceptions_to_ignore:
>             pass
>         except self.exceptions_to_pass_on:
>             raise  #Python idiom for re-throwing the exception
>         except self.exceptions_to_log, exc:
>             print "Exception raised", exc

    Excellent Python lesson by the way. I understand clearly it
    because it maps to an interface that is burned into my retinas.

    Let's say, rather than simply raise, pass, or log, you want to
    give the person who constructed this object a chance to fix.
    
    A chance to select a different enocoding, or some such.

    So, in addition to raise, pass, or log, how do you provide a
    means to fix.

    It might be a form of error handler in an any language. If
    that's the answer that pops out at everyone else, good, cause
    that's what's popping out at me.

> I think this provides just about all the flexibility one might want in
> marshalling exceptions, FWIW.

    Looks great. I really like using a set to match blocks in the
    catch ladder. It would fix problems with exception heirarchies
    that are too flat, like the reflection exception heirarchy in Java.

    Cheers.
 
-- 
Alan Gutierrez - alan@engrm.com