Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: Alex Karasulu <aok123@bellsouth.net>
Organization: Solarsis Group
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: RE: [codec] DecoderException superclass [WAS: StatefulDecoders]
Date: Wed, 25 Feb 2004 16:22:23 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: 
 <20040225212223.MFXL1897.imf18aec.mail.bellsouth.net@mail.bellsouth.net>

Noel,

You have some very interesting ideas here which I need to process
and consider in depth.  Expect more interfaces for discussion soon.

> 
> From: "Noel J. Bergman" <noel@devtech.com>
> Date: 2004/02/25 Wed PM 03:27:43 EST
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Subject: RE: [codec] DecoderException superclass [WAS: StatefulDecoders]
> 
> > > 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
> 
> 


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