Re: [math] deciding about 2.2 (was Re: [all][math] Help wanted with exceptions API design)

On Wed, Feb 2, 2011 at 4:23 AM, Luc Maisonobe wrote: > Le 02/02/2011 05:54, Phil Steitz a écrit : >> On 2/1/11 2:06 PM, Luc Maisonobe wrote: >>> Le 01/02/2011 18:22, Jörg Schaible a écrit : Hi, Phil Steitz wrote: > We are in process of redesigning our exceptions hierarchy i

RE: [all][math] Help wanted with exceptions API design

> -Original Message- > From: jodastep...@gmail.com [mailto:jodastep...@gmail.com] On Behalf Of > Stephen Colebourne > Sent: Wednesday, February 02, 2011 03:57 > To: Commons Developers List > Subject: Re: [all][math] Help wanted with exceptions API design > >

Re: [all][math] Help wanted with exceptions API design

Hi Gilles, Gilles Sadowski wrote: > Hello. > >> > [...] >> > >> > Do I understand correctly that, if we go down that road, there would >> > only be a single exception (every failure will raise the same >> > exception)? >> >> No, not at all, but your exceptions would provide all the same mechan

Re: [all][math] Help wanted with exceptions API design

On Wed, Feb 02, 2011 at 09:41:12AM +0100, Luc Maisonobe wrote: > Le 02/02/2011 08:53, Gary Gregory a écrit : > > Why are the messages not externalized in a properties file? > > They are externalized in a properties file: > > They enum Phil pointed out here: >http://s.apa

Re: [all][math] Help wanted with exceptions API design

On Wed, Feb 02, 2011 at 07:53:00AM +, Gary Gregory wrote: > Why are the messages not externalized in a properties file? The translations are (currently, only French is available). Having the default messages inside a class (using the "constructor" feature for enums) is perhaps more efficient

Re: [all][math] Help wanted with exceptions API design

Hi. > My new approach to coding. Say what you see. Expressed with other words, but that's indeed what I'm suggesting for CM. > a) is IllegalArgEx (JDK) or a subclass. > b) is CalculationException or a subclass if there is truly valuable info to > add > c) some other random RuntimeException Al

Re: [all][math] Help wanted with exceptions API design

On Wed, Feb 02, 2011 at 08:57:10AM +, Stephen Colebourne wrote: > On 2 February 2011 00:12, Gilles Sadowski > wrote: > >> Here is a probably too simple example: > >> > >> com.example defines IOException > >> com.example.input uses IOException > >> com.example.output uses IOException > > > > W

Re: [all][math] Help wanted with exceptions API design

Hello. > > [...] > > > > Do I understand correctly that, if we go down that road, there would only > > be a single exception (every failure will raise the same exception)? > > No, not at all, but your exceptions would provide all the same mechanism to > add valuable information up the stack. Ha

Re: [all][math] Help wanted with exceptions API design

On Tue, Feb 01, 2011 at 10:40:47PM -0800, Stephen Williams wrote: > On 2/1/11 10:04 PM, Phil Steitz wrote: > >... > >Agreed. This is why we had a very flat hierarchy through version > >2.0 of [math]. Where we are having trouble gaining consensus is how > >to represent specializing context informa

Re: [all][math] Help wanted with exceptions API design

Hi. > [...] > > Trap for retry errors should be rare if present at all. I would much > > prefer to see a proper result object which everyone is forced to check > > to describe the success or failure of something that might be retried. > "Retry" is not in general meaningful for our stuff, though in

Re: [all][math] Help wanted with exceptions API design

Hi. > >I know I've recently seen a great example of a library that > >started with generic exception classes then later changed to a > >specific hierarchy. But I can't remember off hand which library > >it was... > > > >There is some low level where you just want to get back the raw > >exception,

Re: [math] deciding about 2.2 (was Re: [all][math] Help wanted with exceptions API design)

On 2 February 2011 09:23, Luc Maisonobe wrote: > It seems the thread asking for help on the exception API design is going > to be fruitful, and it starts well with interesting ideas. I guess some > of these ideas will change again our view and we will converge > (hopefully not throwing an exceptio

[math] deciding about 2.2 (was Re: [all][math] Help wanted with exceptions API design)

Le 02/02/2011 05:54, Phil Steitz a écrit : > On 2/1/11 2:06 PM, Luc Maisonobe wrote: >> Le 01/02/2011 18:22, Jörg Schaible a écrit : >>> Hi, >>> >>> Phil Steitz wrote: >>> We are in process of redesigning our exceptions hierarchy in [math] and we could use some input / perspective from ot

Re: [all][math] Help wanted with exceptions API design

On 2 February 2011 06:04, Phil Steitz wrote: > What we report back to the application using [math] is that one of > the following kinds of bad things has happened > > a) they have violated preconditions - they get > MathIllegalArgumentException (same semantics as anywhere else) > b) they have not

Re: [all][math] Help wanted with exceptions API design

On 2 February 2011 00:12, Gilles Sadowski wrote: >> Here is a probably too simple example: >> >> com.example defines IOException >> com.example.input uses IOException >> com.example.output uses IOException > > Well, I don't see that as obviously better than storing all exceptions in an > "exceptio

Re: [all][math] Help wanted with exceptions API design

Le 02/02/2011 08:53, Gary Gregory a écrit : > Why are the messages not externalized in a properties file? They are externalized in a properties file: They enum Phil pointed out here: >http://s.apache.org/NNd> defines a default English message in case a message is not tra

Re: [all][math] Help wanted with exceptions API design

Why are the messages not externalized in a properties file? Gary On Feb 1, 2011, at 23:55, "Phil Steitz" wrote: > On 2/1/11 2:06 PM, Luc Maisonobe wrote: >> Le 01/02/2011 18:22, Jörg Schaible a écrit : >>> Hi, >>> >>> Phil Steitz wrote: >>> We are in process of redesigning our exceptions

Re: [all][math] Help wanted with exceptions API design

Hi Gilles, Gilles Sadowski wrote: >> > [...] >> > >> > Has anyone of you considered the usage of an exception context? We >> > introduce this with lang3 (http://commons.apache.org/lang/api-3.0- >> > beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it >> > basically adds a map w

Re: [all][math] Help wanted with exceptions API design

On 2/1/11 10:04 PM, Phil Steitz wrote: ... Agreed. This is why we had a very flat hierarchy through version 2.0 of [math]. Where we are having trouble gaining consensus is how to represent specializing context information in our exceptions and what abstractions to use to represent the shallow h

Re: [all][math] Help wanted with exceptions API design

On 2/1/11 6:38 AM, Stephen Colebourne wrote: > I can give some feedback based on JSR-310. > > I have a small hierarchy of exceptions that attempts to capture some > key problems that may occur. The problem I found was that as I > refactored code, the exceptions listed in Javadoc quickly became > in

Re: [all][math] Help wanted with exceptions API design

On 2/1/11 2:06 PM, Luc Maisonobe wrote: > Le 01/02/2011 18:22, Jörg Schaible a écrit : >> Hi, >> >> Phil Steitz wrote: >> >>> We are in process of redesigning our exceptions hierarchy in [math] >>> and we could use some input / perspective from other Commons >>> community members. Thanks in advanc

Re: [all][math] Help wanted with exceptions API design

es, as inner classes is often better also. I think of it as being object oriented at the next level up of granularity. Stephen On 2/1/11 3:27 PM, Gary Gregory wrote: -Original Message- From: Gilles Sadowski [mailto:gil...@harfang.homelinux.org] Sent: Tuesday, February 01, 2011 18:1

Re: [all][math] Help wanted with exceptions API design

On Tue, Feb 01, 2011 at 11:27:26PM +, Gary Gregory wrote: > > -Original Message- > > From: Gilles Sadowski [mailto:gil...@harfang.homelinux.org] > > Sent: Tuesday, February 01, 2011 18:16 > > To: dev@commons.apache.org > > Subject: Re: [all][math] Help wan

Re: [all][math] Help wanted with exceptions API design

> > [...] > > > > Has anyone of you considered the usage of an exception context? We > > introduce > > this with lang3 (http://commons.apache.org/lang/api-3.0- > > beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it > > basically adds a map with key/value pairs to the exceptio

RE: [all][math] Help wanted with exceptions API design

> -Original Message- > From: Gilles Sadowski [mailto:gil...@harfang.homelinux.org] > Sent: Tuesday, February 01, 2011 18:16 > To: dev@commons.apache.org > Subject: Re: [all][math] Help wanted with exceptions API design > > > > > > The currently defined exc

Re: [all][math] Help wanted with exceptions API design

> > > > The currently defined exceptions in [math] can be found in the > > > > top-level package and .exceptions.  Those in the top-level have at > > > > this point been deprecated. > > Don't package your exceptions in a package called ".exceptions". That is very > odd. Why? > The exception sho

RE: [all][math] Help wanted with exceptions API design

> -Original Message- > From: Luc Maisonobe [mailto:luc.maison...@free.fr] > Sent: Tuesday, February 01, 2011 14:07 > To: Commons Developers List > Subject: Re: [all][math] Help wanted with exceptions API design > > Le 01/02/2011 18:22, Jörg Schaible a écrit : > &

Re: [all][math] Help wanted with exceptions API design

Le 01/02/2011 18:22, Jörg Schaible a écrit : > Hi, > > Phil Steitz wrote: > >> We are in process of redesigning our exceptions hierarchy in [math] >> and we could use some input / perspective from other Commons >> community members. Thanks in advance for your feedback and perspective. >> >> The

Re: [all][math] Help wanted with exceptions API design

Hi, Phil Steitz wrote: > We are in process of redesigning our exceptions hierarchy in [math] > and we could use some input / perspective from other Commons > community members. Thanks in advance for your feedback and perspective. > > The most recent attempt at agreeing on design principles is [

Re: [all][math] Help wanted with exceptions API design

Uhh... What about IOException? I was under the impression that people use that ALL the time. The specializations EOFException and FileNotFoundException are very handy when you want the specific case and the general version is nice when you want to trap and possibly wrap all of the exceptions in

RE: [all][math] Help wanted with exceptions API design

> -Original Message- > From: luc.maison...@free.fr [mailto:luc.maison...@free.fr] > Sent: Tuesday, February 01, 2011 08:52 > To: Commons Developers List > Subject: Re: [all][math] Help wanted with exceptions API design > > <...> > > > The currently

Re: [all][math] Help wanted with exceptions API design

Hi. > >> I have a small hierarchy of exceptions that attempts to capture some > >> key problems that may occur. The problem I found was that as I > >> refactored code, the exceptions listed in Javadoc quickly became > >> inaccurate. As a result, I've started converting many exceptions to > >> the

Re: [all][math] Help wanted with exceptions API design

On 1 February 2011 13:52, wrote: >> I have a small hierarchy of exceptions that attempts to capture some >> key problems that may occur. The problem I found was that as I >> refactored code, the exceptions listed in Javadoc quickly became >> inaccurate. As a result, I've started converting many e

Re: [all][math] Help wanted with exceptions API design

- "Stephen Colebourne" a écrit : > I can give some feedback based on JSR-310. > > I have a small hierarchy of exceptions that attempts to capture some > key problems that may occur. The problem I found was that as I > refactored code, the exceptions listed in Javadoc quickly became > inaccu

Re: [all][math] Help wanted with exceptions API design

Hi. On Tue, Feb 01, 2011 at 11:38:04AM +, Stephen Colebourne wrote: > I can give some feedback based on JSR-310. Thank you for sharing ideas. > I have a small hierarchy of exceptions that attempts to capture some > key problems that may occur. The problem I found was that as I > refactored c

Re: [all][math] Help wanted with exceptions API design

I can give some feedback based on JSR-310. I have a small hierarchy of exceptions that attempts to capture some key problems that may occur. The problem I found was that as I refactored code, the exceptions listed in Javadoc quickly became inaccurate. As a result, I've started converting many exce

[all][math] Help wanted with exceptions API design

We are in process of redesigning our exceptions hierarchy in [math] and we could use some input / perspective from other Commons community members. Thanks in advance for your feedback and perspective. The most recent attempt at agreeing on design principles is [1] and I have tried to document the