commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
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 Tue, 06 Jul 2010 12:06:59 GMT
Le 06/07/2010 11:20, Gilles Sadowski a écrit :
>>>> 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
>>>> 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!

I am thinking about the programs I use: space flight dynamics programs
that do things like orbit propagation, operational events forecasts
(eclipse entry/exit, visibility from ground station, apogee/perigee/node
crossings, South Atlantic Anomaly entry/exit, thrusters firings,
Sun/Moon/stars visibility/dazzling in optical sensors ...), orbit
determination, maneuver optimization, space debris close approaches and
avoidance ...

These applications are often integrated into a large framework (a
satellite control enter). They provide graphical user interface. The
errors are often displayed in limited dedicated places (error message
line at the bottom of some windows, popup window with one or two text
lines, and most of the time a single line of text transmitted to a
centralized log application gathering messages from the whole control enter.

Another example are web applications. The interactive part runs on a
browser and the core engine runs on the server. The messaging protocol
between the two doesn't provided anything but a string to display error
messages, and the UI is often designed for one line strings, not 50
lines stack traces.

A third example are applications running on limited mobile devices like
phones. The display is very limited, it would not handle a 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.

The problem we discuss is not related to Java, it is all about
ergonomics. The rules about error messages are consistent everywhere I
looked: they should be user oriented, helpful and must not rely on
program implementation details. When I read:
  "provide user-centered wording in messages (e.g. "there was a problem
   in copying the file to your disk" rather than "execution error 159")"
in <>, I
consider it also rules out stack traces.

Of course, Phil you and I can deal with stack traces. In fact, I think
all people on this list (a "dev" list) can and do this all the time. But
users may not. You consider our users are developers (I think you wrote
it some days ago) and we are not concerned by the users of our users.
However, since at the same time you ask for going to unchecked exception
which will obviously lead to our messages leaking to the higher level
and to final user, I cannot agree with both points at the same time.

If all messages should be tracked and handled by intermediate code, and
if they are only meant to developers with their accompanying stack
trace, then they must be checked exception to be sure no error is
missed. If we opt for unchecked exception, there will be leaked messages
and the stack trace will sometimes not be there (or will be theere for a
user than cannot understand or use them). This look to me similar to
this wonderful analysis of a web server error message:
<>; of course from a
developer or an experienced user, the message is self explanatory, but
consider how it may be misinterpreted by a less experienced user.

To me, the trade-off between our diverging points is to:
 1) go to uncheck exceptions wherever possible (your point)
 2) reduce number of difference messages (everybody point)
 3) keep informational messages (both Phil and mine point)

Items 2 and 3 are sometimes in contradiction and should be applied on a
message by message basis.


>>> 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
> and/or at
> 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.
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message