commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [codec] DecoderException superclass [WAS: StatefulDecoders]
Date Wed, 25 Feb 2004 20:27:43 GMT
> > I think the introduction of EncoderException and DecoderException
> > in and of itself was a mistake in the first place.
> > Encoder and Decoder are similar to Reader and Writer which both
> > throw IOException.

> I agree fully.

I disagree fully, as I will explain.

> Decode and encode operations are a special case of filter operations
> Filtering is inherently an IO operation where any failure should be
> represented as some form of IOException.

No it is not.  I think it is important to change the mindset, and realize
that there is no I/O (LOL for some reason, this is sounding like a scene
from The Matrix).  I/O may be performed by suppliers to feed the pipeline,
or by consumers receiving events within, but the pipline itself is no more
involved in I/O abstractions than a linked  list manager has to be involved
in I/O.

With respect to exception handling, the approach that JavaMail took isn't
too bad.  They created MessagingException, which does two things: (1) it
establishes a domain, rather than just Exception; and (2) it supports
chaining, which is only recent to Java.  Our interfaces would expose our
domain exception(s) as appropriate.  If we have a purpose to create a
subclass to provide specialized information, that's fine.  If we encounter
(or need to create) standard checked exceptions, we chain them in our basic
exception.  So most operations would look like:

  public T op(...) throws E';

although I think that when I/O is clearly part of the operation, you don't
play games by chaining the I/O exception.  You just do:

  public T op(..., IO-thing ,...) throws E', IOException;

Such a thing would only be exposed in convenience/legacy wrappers, since the
actual pipeline is totally decoupled from I/O.

The real keys here, and the things we want to get right, are the pipeline
interfaces and architecture.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message