You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@yahoo.com> on 2001/07/02 00:58:25 UTC
Re: [RT] IoC in exception handling?
IoC does not really apply to Exception handling.
Logically, all that is happening is that the method
is returning early with a class that has error
information attached to it. It is well understood
for most programmers.
Using any other approach only serves to add a layer
of complexity with no real advantage. Exceptions
are used to exit a method early--the approach you
outlined merely calls a method on a calling class.
Exceptions are method-centric, not class-centric.
--- Jeff Turner <je...@socialchange.net.au> 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:
> avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> avalon-dev-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] IoC in exception handling?
Posted by Berin Loritsch <bl...@apache.org>.
Jay Doane wrote:
>
> Berin Loritsch writes:
>
> > > (Looking forward to that Avalon whitepaper/research
> > > thingy of yours:)
> >
> > It is in CVS (in DocBook format)
>
> Where, specifically, can I can find it in CVS?
${avalon-root}/src/xdocs/developing
The main doc (index.xml) uses XInclude to include the other parts.
However, the useful info is in each of the other documents.
Re: [RT] IoC in exception handling?
Posted by Jay Doane <ja...@almery.com>.
Berin Loritsch writes:
> > (Looking forward to that Avalon whitepaper/research
> > thingy of yours:)
>
> It is in CVS (in DocBook format)
Where, specifically, can I can find it in CVS?
Thanks,
Jay
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] IoC in exception handling?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Thu, 5 Jul 2001 09:03, Berin Loritsch wrote:
> > > That depends on the component. If your component
> > > requires deferred or
> > > non-critical exception handling, try/catch isn't
> > > good enough. That's why
> > > Mr Megginson came up with org.xml.sax.ErrorHandler.
>
> yep ;) Basically I see ErrorHandler as a strategy for dealing with the
> exception aspect. Damn useful it is but I am a loss at how to integrate it
> generically.
You'd be surprised at how closely the semantics of Error Handling in this
manner are closely tied to the semantics of the contracts for a particular
system. IOW, Each EventHandler strategy pretty much needs their own ErrorHandler.
There are different types and classes of errors that will only work for certain
systems. Also, you have to realize (using the venerable SAX API as an example)
that SAX is a PITA to use if you are going to do complex transformations on the
fly. It is easier to transform a DOM than SAX. I am not saying it can't be
done (just look at Xalan 2), I am saying that there are always different approaches
to solving a problem space. You have to evaluate which tool is the right one
for the job.
> > Component creation and lifecycle management are not
> > cleanly served by that approach.
>
> Depends on what you call "lifecycle management" ;) I have found it useful in
> two places. One is in containers to implement different exception handling
> strategies and one is in the "service" part of an "active" component. ie Each
> time you call the relevent service method you pass in relevent handler.
I call lifecycle management the process of calling the lifecycle methods:
comp.setLogger(logger)
comp.contextualize(context)
comp.configure(conf)
comp.parameterize(params)
comp.compose(manager)
comp.initialize()
comp.start()
etc.
This can be done in a number of ways--so if you have a particular method in Phoenix
which would benefit from an ErrorHandler of sorts. The thing is that if an exception
is thrown at any time during the initialization phase, the Component cannot be
guaranteed to be in a sane state--so the only safe assumption is that we cannot use
the component that threw exceptions during initialization.
Re: [RT] IoC in exception handling?
Posted by Peter Donald <do...@apache.org>.
On Thu, 5 Jul 2001 09:03, Berin Loritsch wrote:
> > That depends on the component. If your component
> > requires deferred or
> > non-critical exception handling, try/catch isn't
> > good enough. That's why
> > Mr Megginson came up with org.xml.sax.ErrorHandler.
yep ;) Basically I see ErrorHandler as a strategy for dealing with the
exception aspect. Damn useful it is but I am a loss at how to integrate it
generically.
> Component creation and lifecycle management are not
> cleanly served by that approach.
Depends on what you call "lifecycle management" ;) I have found it useful in
two places. One is in containers to implement different exception handling
strategies and one is in the "service" part of an "active" component. ie Each
time you call the relevent service method you pass in relevent handler.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] IoC in exception handling?
Posted by Berin Loritsch <bl...@yahoo.com>.
--- Jeff Turner <je...@socialchange.net.au> wrote:
> On Sun, Jul 01, 2001 at 03:58:25PM -0700, Berin
> Loritsch wrote:
> > IoC does not really apply to Exception handling.
> > Logically, all that is happening is that the
> method
> > is returning early with a class that has error
> > information attached to it. It is well understood
> > for most programmers.
> >
> > Using any other approach only serves to add a
> layer
> > of complexity with no real advantage.
>
> That depends on the component. If your component
> requires deferred or
> non-critical exception handling, try/catch isn't
> good enough. That's why
> Mr Megginson came up with org.xml.sax.ErrorHandler.
>
> Perhaps I'm not alone in this.. I've always thought
> of SAX as *the* most
> widely known example of IoC in a Java API. As such,
> it seems natural to
> wonder whether SAX's unusual error handling is a
> consequence of it's
> "invertedness", and if so, whether this has
> implications for Avalon.
SAX is not IoC. SAX is an Event Handling framework
designed to communicate the structure of an XML
document one piece at a time. When you have
Components that employ Event Handling (like SAX),
then the ErrorHandler approach is a natural extention
to the framework because you now have new event types
to handle. There is no control explicitly
communicated
between the Event Producer and the Handler.
The key distinction between SAX and IoC is the
semantic of Information vs. Control. SAX is
information based--not control based. The interfaces
in Avalon are IoC because the contracts state that
the target Component/Object is being controlled by
another.
Remember, you must use the right tool for the job.
Sometimes you need a sledgehammer, and sometimes you
need rubber mallet. Keep in mind the distinction that
I laid out for you above. Event Handling information
frameworks are served quite nicely by Error Handling.
Component creation and lifecycle management are not
cleanly served by that approach.
> (Looking forward to that Avalon whitepaper/research
> thingy of yours:)
It is in CVS (in DocBook format), and I have one last
section to put in. Finding time is difficult though.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] IoC in exception handling?
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Jul 01, 2001 at 03:58:25PM -0700, Berin Loritsch wrote:
> IoC does not really apply to Exception handling.
> Logically, all that is happening is that the method
> is returning early with a class that has error
> information attached to it. It is well understood
> for most programmers.
>
> Using any other approach only serves to add a layer
> of complexity with no real advantage.
That depends on the component. If your component requires deferred or
non-critical exception handling, try/catch isn't good enough. That's why
Mr Megginson came up with org.xml.sax.ErrorHandler.
Perhaps I'm not alone in this.. I've always thought of SAX as *the* most
widely known example of IoC in a Java API. As such, it seems natural to
wonder whether SAX's unusual error handling is a consequence of it's
"invertedness", and if so, whether this has implications for Avalon.
--Jeff
(Looking forward to that Avalon whitepaper/research thingy of yours:)
> Exceptions are used to exit a method early--the approach you outlined
> merely calls a method on a calling class. Exceptions are
> method-centric, not class-centric.
>
>
> --- Jeff Turner <je...@socialchange.net.au> 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 unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org