commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable
Date Tue, 09 Jul 2002 06:31:20 GMT
Seems to me there are only two real options.

Index access or linked access.

I agree with Laird that if we're going to go and do the array/List
approach for indexed access, that it would be better for us to provide a
[JavaBean like hopefully] indexed access instead. If we're going to this
amount of trouble, then why not supply the Throwable instead of the
message. Which takes us back to having a getMessage() for deep access, a
getCause() for shallow, and then an indexed list of Throwables in some
way.

The other option would be linked/chained access. Rather than the index we
would have a getNextThrowable which would return the next throwable in the
chain. Optionally we could also have a getNextNestable to save them with
casting issues. One nice thing being that we could then support JDK 1.4
possibly, automatically wrapping any java.lang nested exception.

Juss ideas.

Hen

On Mon, 8 Jul 2002, Laird J. Nelson wrote:

> I'd vote for indexed access instead (getMessage(int)) so that you don't
> end up slinging arrays or Lists around with null elements in them.
> Also, by indicating that you need those placeholders, you're saying that
> the *position in* the list matters, which is just another way of saying
> that the *index* matters, which is surreptitiously voting for indexed
> access.  :-)
>
> I also think we're probably going to ultimately want access to the
> nested exceptions themselves, not just their messages.  Obviously you
> could implement the latter in terms of the former, but, equally
> obviously, not the other way around.  How about a getThrowable(int)
> method that digs that deeply into the Nestable "chain", thus treating it
> as a linked list?  Then your convenience getMessage(int) method
> piggybacks on top of that.
>
> Ninety nine times out of one hundred you want the first or the last
> exception/message in the list, but why not provide indexed access to
> both?
>
> Another type of accessor that is REALLY useful is something like:
>
>   getThrowable(int, Class)
>
> (or I guess it would be called getNestable(int, Class)), which returns
> the nth zero-based occurence of a Nestable provided it's an instance of
> the supplied class.  So you can effectively say "get me the first
> SQLException in the chain" so you can dig down into the chain and get
> out the SQL code, for example.
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/foundry/foundr
> y/foundry/throwables/Throwables.java?rev=1.3 is my crack at solving some
> of these problems; happy to donate if you can stand the smell of the
> code (there are some ugly cross dependencies that work but ain't
> pretty).  :-)
>
> Cheers,
> Laird
>
> > -----Original Message-----
> > From: Steven Caswell [mailto:steven@caswell.name]
> > Sent: Monday, July 08, 2002 8:14 PM
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [lang] patch to Nestable interface, exception
> > implementation classes, and test cases to get message specific to the
> > nestable
> >
> >
> > I'm assuming that in the getMessages() return, a Throwable in
> > the chain
> > without a message should have either a null or a blank placeholder. My
> > vote is for null so as to distinguish between a real blank message.
> > However, using null would preclude use of a List as a return
> > type since
> > List implementations are not guaranteed to allow null entries.
> >
> >
> > Steven Caswell
> > steven@caswell.name
> > a.k.a Mungo Knotwise of Michel Delving
> > "One ring to rule them all, one ring to find them..."
> >
> >
> > > -----Original Message-----
> > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > Sent: Monday, July 08, 2002 4:36 PM
> > > To: Jakarta Commons Developers List; ljnelson94@alumni.amherst.edu
> > > Subject: Re: [lang] patch to Nestable interface, exception
> > > implementation classes, and test cases to get message
> > > specific to the nestable
> > >
> > >
> > > I favour this approach of having an accessible list rather
> > > than fixed access. If we are to do this I would like the
> > > change to be made now. It would involve replacing the
> > > recently added getNextMessage() method with the more generic
> > > getMessages() that returns a List of Strings (or a string
> > > array). getFirst and getLast message could stay. Opinions?
> > >
> > > Stephen
> > >
> > > ----- Original Message -----
> > > From: "Laird J. Nelson" <lairdnelson@earthlink.net>
> > > > > From: Henri Yandell [mailto:bayard@generationjava.com]
> > > > > > > From: Steven Caswell [mailto:steven@caswell.name]
> > > > > > > > From: Henri Yandell [mailto:bayard@generationjava.com]
> > > > > > > > I may be misunderstanding, but getBaseMessage returns
the
> > > > > > > > message at the top level of the Exception, ie) the
> > > most recent
> > > > > > > > message.
> > > > > > > Correct
> > > > > > > > Should we also have:
> > > > > > > > getNestedMessage() which returns the Exception at
> > the next
> > > > > > > > level down, and
> > > > > > > > getDeepNestedMessage() which returns the Exception
at the
> > > > > > > > bottom, assuming all Exceptions in the chain implement
> > > > > > > > Nestable?
> > > > Another approach to take might be to treat composite
> > > exceptions like
> > > > this like a linked list.  I've done something similar with my own
> > > > ThrowableChain class (javadocs available at
> > > >
> > > http://foundry.sourceforge.net/docs/api/foundr>
> > y/throwables/ThrowableCh
> > > > ai
> > > > n.html).  I've found that being able to get the length of
> > > the chain, get
> > > > the "ith" exception in the chain, etc. is really helpful,
> > especially
> > > > when determining the message to show to the end user.
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


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


Mime
View raw message