commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: RE: [codec] DecoderException superclass [WAS: StatefulDecoders]
Date Wed, 25 Feb 2004 21:22:23 GMT
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


Mime
View raw message