On Fri, Jun 29, 2001 at 12:02:21AM +1000, Peter Donald wrote:
> I actually tried to do this for Avalon/Phoenix and could not figure out a
> nice way to do it at all. When reporting exceptions to handler instance you
> need some information about what/where exception came from. At one extreme
> you have very specific handler arrangment like
>
> interface MyErrorHandler
> {
> void fileNotFoundException( String filename, IOException ioe );
> void fileNotReadableException( String filename, IOException ioe );
> void fileNotWritableException( String filename, IOException ioe );
> ...
> }
>
> and at the other there is
>
> interface MyErrorHandler
> {
> void warn( String action, String target, Throwable t );
> void error( String action, String target, Throwable t );
> }
>
> where action would be something like "java.io.File.open" and target would be
> the filename. Obviously option 1 is not workable in any generic fashion. The
> question becomes is version 2 generic and usable. I guess like Leo Sutic, I
> could see where this behaviour would be bad. So I am not sure which behaviour
> is best/worst ;)
I can see that both those methods are pretty unlovable. Too generic..
"hyperflexiblility syndrome" as LS said.
Still, in certain situations (like XML parsing), using an ErrorHandler
interface is a pretty nice way to go. Especially when:
- warnings are distinct from errors.
- multiple warnings/errors can occur during one execution, and you
don't want to stop on the first.
- you may want to recover from exceptions/warnings.
These requirements crop up a lot in server-side programming, hence my
poorly thought through suggestion to formalize them in Avalon..
Thanks for the feedback.. gets my brain ticking over.
--Jeff
> Either way I wouldn't want to place it in framework proper until it has seen
> more testing.
>
> On Fri, 29 Jun 2001 00:10, Jeff Turner wrote:
> > Hi,
> >
> > Java's exception handling is "active". It is driven by the callee, not
> > the caller. When an exception is thrown, the callee effectively calls
> > the catch {} block of the caller. So now if I'm using a passive API like
> > Avalon, and a Component throws an exception, doesn't that break IoC?
> > Since when does "a passive entity that performs a specific role"[1] get
> > to tell me, the caller, what to do?
> >
> > To use the army "chain of command" analogy in the Avalon docs, a
> > Component throwing an exception is like a soldier forgetting their
> > orders, giving up and going home as soon as something goes wrong. If
> > that was the case, wars would not get fought and where would we all be
> > now, I should like to know? ;)
> >
> > Wouldn't it be more appropriate to have a passive exception handling
> > system. We must acknowledge that, when a problem occurs, the callee
> > *must* contact the caller. The roles must temporarily be reversed. So
> > how about using a passive SAX-like exception handling mechanism, where
> > the caller provides an ErrorHandler[2] implementation, which the callee
> > calls?
> >
> > Here's an example. Let's say our Component wants to throw a fatal
> > exception. The regular Java exception handling, our caller would have:
> >
> > class Caller {
> > ..
> > try {
> > callee.doSomething();
> > } catch (SomeException e) {
> > // handle error
> > ..
> > }
> > ..
> > }
> >
> > and our callee would simply have:
> >
> > class Callee {
> > public void doSomething() throws SomeException {
> > ..
> > if (error) throw new SomeException("oops");
> > ..
> > }
> > ..
> > }
> >
> > Using a passive SAX-like ErrorHandler system, the caller could be
> > written:
> >
> > class Caller implements ErrorHandler {
> >
> > ..
> > callee.setErrorHandler(this);
> > ..
> > callee.doSomething();
> > ..
> >
> > public void error(SomeException e) {
> > // handle error
> > ..
> > }
> > }
> >
> > And the callee:
> >
> > class Callee {
> > public void doSomething {
> > ..
> > if (error) {
> > errHandler.error(new SomeException("oops"));
> > return;
> > }
> > ..
> > }
> >
> > public void setErrorHandler(ErrorHandler e) {
> > ..
> > }
> > }
> >
> > Now why is that better? Mostly because it allows for finer control. The
> > callee can issue warnings on non-critical errors. It doesn't *have* to
> > exit on an error; it can "soldier on" if necessary, safe in the
> > knowledge that it's caller has been notified. This allows the callee to
> > throw multiple exceptions. Imagine the callee is managing threads, 3 of
> > which time out; how would you notify the caller of this with regular
> > Java exception handling?
> >
> > Does the ErrorHandler system preserve IoC better than the first? Damn..
> > now I'm not so sure.. The choice is between the callee calling the
> > caller directly (throwing an Exception), or calling a well-defined
> > interface (ErrorHandler). However, in both cases, the callee **need know
> > nothing about the caller**.
> >
> > Um. So actually, exception handling doesn't break IoC. But then it's
> > demonstrably a lot less powerful than an ErrorHandler mechanism.
> >
> > So how about providing, in org.apache.avalon.framework, an ErrorHandler
> > interface and DefaultErrorHandler implementation, just like SAX does?
> > That way, most people can continue to use Java's built-in exception
> > handling, and those who need the extra control can use ErrorHandlers,
> > all within the Avalon framework.
> >
> >
> > --Jeff
> >
> > (who apologises for rambling, and changing his mind halfway..)
> >
> >
> > [1] http://jakarta.apache.org/avalon/framework/what-is-a-component.html
> > [2] http://www.megginson.com/SAX/Java/javadoc/org/xml/sax/ErrorHandler.html
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
