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 >>>> 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!
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 <http://ergo.human.cornell.edu/ahtutorials/interface.html>, 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: <http://blog.use-design.com/2008/bad-bad-user/>; 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. Luc > >>> 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. > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
