commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.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 21:38:37 GMT
Yes, confusion is possible as you describe. Your idea seems sound, but I
would suggest
int indexOfThrowable(Class type)
int indexOfThrowable(int pos, Class type)
to be the interface. The names are familiar from String ;-)

Stephen

----- Original Message -----
From: "Michael A. Smith" <mas@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Tuesday, July 09, 2002 10:14 PM
Subject: Re: [lang] patch to Nestable interface, exception implementation
classes, and test cases to get message specific to the nestable


> On Tue, 9 Jul 2002, Stephen Colebourne wrote:
>
> > OK, so my spec for the Nestable code would be as follows:
> >
> > String getMessage(int)
> > String[] getMessages()
> > Throwable getThrowable(int)
> > Throwable[] getThrowables()
> > Throwable getThrowable(int, Class)  -- see below
> >
> > I am using arrays, to get towards 1.1 compatability.
> >
> > Comments? I think this interface covers all the needs discussed so far
;-)
>
> I haven't been paying too much attention here, but I thought I'd comment
> anyway.  :)
>
> Would the Throwable getThrowable(int, Class) use the same index as
> getMessage(int) would?  From the description I gathered from the quoted
> mail, it sounded like that was not the case, and thus a possibility for
> confusion.  That is, I understood it to mean that getThrowable(0,
> java.sql.SQLException.class) would return the zeroth (first) throwable
> that was an SQLException.  If that's the case, I would think the
> interface would be a bit confusing.
>
> An alternative would be to use:
>
>   int findThrowable(int, Class)
>
> or something similar.  The integer is the same as all the other integer
> arguments (an index into the array of nested throwables), and represents
> the starting index to search.  The Class indicates the throwable type to
> look for and the return value is the index of the first throwable that
> matches the class with an index greater than or equal to the starting
> index.
>
> If I'm understanding the getThrowable(int, Class) method properly, this
> could be implemented using (ignoring the "not found" case):
>
>   getThrowable(findThrowable(0, java.sql.SQLException.class))
>
> to get the nth one, you could use:
>
>   int pos = findThrowable(0, java.sql.SQLException.class);
>   for(int i = 0; i < nth && pos != -1; i++) {
>     pos = findThrowable(pos, java.sql.SQLException.class);
>   }
>   if(pos != -1) {
>     t = getThrowable(pos);
>   } else {
>     // not found
>     t = null;
>   }
>
> Seems like this provides a bit more flexibility for "searching" for
> throwables of a particular type.
>
> On another note though, is there ever a case where you'll need other
> than the first of a particular type?
>
> michael
>
>
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Laird J. Nelson" <lairdnelson@earthlink.net>
> > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
> > <steven@caswell.name>
> > Sent: Tuesday, July 09, 2002 4:15 AM
> > Subject: RE: [lang] patch to Nestable interface, exception
implementation
> > classes, and test cases to get message specific to the nestable
> >
> >
> > > 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>
> >
>
>
>
> --
> 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