commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: svn commit: r960602 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/interpolation/ main/java/org/apache/commons/math/exception/ main/java/org/apache/commons/math/util/ main/resources/META-INF/localization/ site/xdoc/ tes...
Date Wed, 07 Jul 2010 10:27:43 GMT
Gilles Sadowski wrote:
>>>> The stack trace certainly will show where the bad thing happened.
>>>> Nothing important is lost: What went wrong is as clearly identified by
>>>> saying
>>>>  "The argument must be >= 2"
>>>> as by saying
>>>>  "The number of points must be >= 2"
>>>> The problem is that the caller passed a wrong argument and this is a bug
and
>>>> no amount of detailed message will be a substitute for reading the
>>>> documentation and source code and make the correct call.
>>> Sorry, but I disagree here.  There is definitely loss of information
>>> in the stack trace. I would prefer to retain the detailed error
>> I also disagree with Gilles, but not the same reason. Some people will
>> not have access to the stack trace. It is even more important for
>> unchecked exception since they may not be intercepted by high level
>> applications. All they will get is a terse message print on a log file
>> or a popup window before the application stops.
>>
>> Users are not here to debug the code for developers.
>>
>> Also the Apache license allows people to reuse our code in proprietary
>> environment with closed source. For sure in this case, no stack trace
>> will be available.
>>
>> Luc
> 
> And I disagree with both your disagreements. Could you _please_ answer all
> the drawbacks of your approach in several scenarios which I've put forward
> many times already, instead of always only cling to the one use-case which
> you are interested in?
> 
> Please! What kind of ?@#! application is it that you take as an example,
> that will print a terse message and exit?  The _least_ a program should
> do when it bails out is print the stack trace!
> 
> Please! Read chapter 8 of Bloch's Effective Java (less then 20 pages) to see
> that indeed the error message must be reported by the user/operator to the
> developer. This is not debugging.
> 
>>> message that tells what quantity was "too small."  And I do not
>>> really see the value in the "NumberTooSmallException" altogether,
>>> frankly.  By substituting an exception that does not identify what
>>> quantity was "too small" for an IllegalArgumeentException with a
>>> message giving the full context, what exactly have we achieved?
> 
> Then perhaps you missed some of the comments here above, and also at
>   https://issues.apache.org/jira/browse/MATH-195
> and/or at
>   https://issues.apache.org/jira/browse/MATH-361
> and references therein (Bloch, Goetz).
> 
> Or perhaps we (Eckel et al.) are all wrong. In this case, please show me
> modern, high-profile, Java library projects that deal with exceptions in
> the same way that you want it for CM.
> 

What is important and relevant to discussion here is how we
structure and manage exceptions in [math].  It is best for us to
keep the discussion focused on concrete examples, with arguments
supported directly using [math] use cases.  Luc and I have provided
examples of use cases where the changes that you are proposing are
not optimal for users.  You need to respond directly to these examples.

The specific change that we are talking about here is the
replacement of an IllegalArgumentException with an error message
containing context information about what argument was "illegal" and
why by a "NumberTooLargeException" containing no reference to the
argument.  I have two problems with this change:

1. There is loss of failure-capture information (i.e., the specific
argument that was out of range)
2. I don't see the value in this abstraction.  We all agree that we
need to add more structure to our exceptions hierarchy.  I may well
be missing something here, but I don't see what this particular
abstraction buys us and in particular why it is the appropriate
abstraction for the context in which it is thrown above.

Can you respond directly to these issues, please?

Phil


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


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


Mime
View raw message