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 ;)
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]
