On Thu, Jun 28, 2001 at 08:36:07PM +0200, Leo Simons wrote:
> > I actually tried to do this for Avalon/Phoenix and could not figure out a
> > nice way to do it at all.
>
> =) Me neither. Exceptions are a language feature; to implement
> a mechanism that offers the same functionality and clarity, and
> satisfies IOC would require a language feature as well.
Well.. what exactly is a try/catch block? It's effectively the caller
defining an interface for how the callee can contact it. You know
anonymous classes; think of:
try {
callee.doIO();
} catch (IOException e) {
// handle error
..
}
as defining an "anonymous interface" IOExceptionHandler. You could do
the same thing without the try/catch syntactic sugar, as follows:
callee.setIOExceptionHandler(
new IOExceptionHandler() {
void handleError(IOException e) {
// handle error
..
}
});
callee.doIO();
If you think of it this way, Java's exception handling is simply a
nicely packaged subset of a more general interface-based exception
handling framework.
Um. Possibly. I'll need to think about that further ;)
> If you define exceptions as the one callback mechanism allowed
> in the component framework, it may not be pretty but it does
> provide some useful functionality.
>
> Moreover, as exceptions are a language-level feature, it is all
> but impossible to disable them. How about RMI-enable components?
I never said disable (or even discourage) normal exception handling ;)
It's just that there are clear cases when it's not general enough (eg in
SAX).
> Avalon might indeed benefit from adapting the Strategy pattern
> in some cases, but again in agreement with TOL (The Other Leo),
> this is not a pattern we should apply to (let alone require for)
> the entire framework.
Yep, I've been convinced ;)
thanks,
--Jeff
> cheers,
>
> LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
