You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Steven Caswell <st...@caswell.name> on 2002/06/26 22:49:46 UTC

[lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

I need to be able to get the message string at the top level of a
Nestable. Currently the only message available (via getMessage()) is the
entire rolled up message of the Nestable and the nested classes. I've
attached a patch to the interface, the two implementation classes, and
the test cases that adds a method getThisMessage() to satisfy this need.
I've run the test cases and everything passes. If this is acceptable
could someone please commit.

TIA
 

Steven Caswell
steven@caswell.name

RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Steven Caswell <st...@caswell.name>.

Sounds like a good approach. Is there a preference to returning a String
array vs. a List? I vote for a String array but I don't feel too
strongly either way.


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" <la...@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: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Steven Caswell <st...@caswell.name>.

I have much of the basic code needed for implementation already in
progress, so I'll go ahead and finish it with the revised API as
discussed. Should be in the next day or so. Thanks to all for the input.


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: Laird J. Nelson [mailto:lairdnelson@earthlink.net] 
> Sent: Tuesday, July 09, 2002 7:43 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
> 
> 
> > -----Original Message-----
> > From: Michael A. Smith [mailto:mas@apache.org]
> > On Tue, 9 Jul 2002, Stephen Colebourne wrote:
> > > 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 ;-)
> > yeah, sounds better.  :)
> 
> Works for me.
> 
> Cheers,
> Laird
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by "Laird J. Nelson" <la...@earthlink.net>.

> -----Original Message-----
> From: Michael A. Smith [mailto:mas@apache.org]
> On Tue, 9 Jul 2002, Stephen Colebourne wrote:
> > 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 ;-)
> yeah, sounds better.  :)

Works for me.

Cheers,
Laird

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by "Michael A. Smith" <ma...@apache.org>.

On Tue, 9 Jul 2002, Stephen Colebourne wrote:
> 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 ;-)

yeah, sounds better.  :)

michael


> 
> Stephen
> 
> ----- Original Message -----
> From: "Michael A. Smith" <ma...@apache.org>
> To: "Jakarta Commons Developers List" <co...@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" <la...@earthlink.net>
> > > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> > > <st...@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" <la...@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: <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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" <ma...@apache.org>
To: "Jakarta Commons Developers List" <co...@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" <la...@earthlink.net>
> > To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> > <st...@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" <la...@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: <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by "Michael A. Smith" <ma...@apache.org>.

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" <la...@earthlink.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
> <st...@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" <la...@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: <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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 ;-)

Stephen

----- Original Message -----
From: "Laird J. Nelson" <la...@earthlink.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<st...@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" <la...@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: <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Henri Yandell <ba...@generationjava.com>.

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" <la...@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: <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by "Laird J. Nelson" <la...@earthlink.net>.

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" <la...@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: <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Steven Caswell <st...@caswell.name>.

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" <la...@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: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Stephen Colebourne <sc...@btopenworld.com>.

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" <la...@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/foundry/throwables/ThrowableChai
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by "Laird J. Nelson" <la...@earthlink.net>.

> -----Original Message-----
> 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?

{lurker emerges from shadows}

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/foundry/throwables/ThrowableChai
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.

{lurker retreats into shadows}

Cheers,
Laird


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] patch to Nestable interface, exception implementation classes, and test cases to get message specific to the nestable

Posted by Henri Yandell <ba...@generationjava.com>.

Done.

On Fri, 5 Jul 2002, Steven Caswell wrote:

> Here is the patch resubmitted with the changes discussed below.
>
>
> 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: Steven Caswell [mailto:steven@caswell.name]
> > Sent: Sunday, June 30, 2002 2:41 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
> >
> >
> > Comments inline...
> >
> >
> > 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: Henri Yandell [mailto:bayard@generationjava.com]
> > > Sent: Sunday, June 30, 2002 2:12 PM
> > > To: Jakarta Commons Developers List; steven@caswell.name
> > > Subject: RE: [lang] patch to Nestable interface, exception
> > > implementation classes, and test cases to get message
> > > specific to the nestable
> > >
> > >
> > >
> > > None seem perfect,but I can't think of anything better than
> > > getBaseMessage.
> > >
> > > 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?
> >
> > I hadn't really though about getting those, but they would be
> > easy to do. I don't know that I like using "Nested" in the
> > names.  How about
> >
> > getNextMessage() which returns the Exception at the next level down
> > getLastMessage() which returns the Exception at the bottom
> >
> > Using that thought process, how about getFirstMessage() instead of
> > getBaseMessage()
> >
> > >
> > > Hen
> > >
> > > On Sun, 30 Jun 2002, Steven Caswell wrote:
> > >
> > > > I don't really like getOriginalMessage because it implies
> > something
> > > > has changed. I think getBaseMessage does a good job of
> > > indicating the
> > > > method's purpose. If folks agree on getBaseMessage I'll make the
> > > > change and resubmit the patch.
> > > >
> > > >
> > > > 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: Sunday, June 30, 2002 6:59 AM
> > > > > 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 aiming to apply it when I next get time to work on
> > > > > Apache, [end of
> > > > > > the month = submission deadline for me]. Everyone happy with
> > > > > > 'getThisMessage' as the method name?
> > > > >
> > > > > I would prefer something like getOriginalMessage, or
> > > getBaseMessage
> > > > >
> > > > > Stephen
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > For
> > > > > additional commands,
> > > > > e-mail: <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > For
> > > additional commands,
> > > e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>