[
Lists Home |
Date Index |
Thread Index
]
At 8:18 AM +0100 3/10/04, Jochen Wiedmann wrote:
>Not quite like the paradigm of exception handling (catch the
>exception in one place).
Throw is different from catch. If you throw a SAXException, then
you're not handling it in that method, which is why you're throwing
it; but you do make the decision of how to configure the object
before throwing the exception. IN many cases you may not need to do
any cleanup at all and can leave the object in an invalid state. You
know whether or not you have to clean up, and what needs to be
cleaned up because you've chosen to throw the exception. This is the
qualitative difference from an exception the parser throws due to bad
input.
>But besides: Who tells you, that *I*
>am throwing the Exception and not, for example, another ContentHandler
>which I invoke?
>
If the other ContentHandler method is declared to throw a
SAXException (the only checked exception it can throw) and you need
to do cleanup, catch it and respond to it and then rethrow it. You
still know where and when the exception can be thrown, which you do
not know for a parser thrown exception.
By the way, although most of the time you can catch an exception in
one place, that's not a rule written in stone. It does happen in more
complicated situations that one catch block has to clean up in one
method and then throw the same or a different exception up to another
method, often in a different class. One of the benefits of the
exception approach compared to traditional error handling is the easy
reversal of the call chain, thus making complicated, multilayered
responses possible.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
- Follow-Ups:
- SAX CVS
- From: David Megginson <dmeggin@attglobal.net>
|
