JDK-4404007 : Exception messages are often uninformative
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.3.0,1.4.0,1.4.2,5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2001-01-11
  • Updated: 2007-04-17
Related Reports
Duplicate :  
Description

Name: boT120536			Date: 01/11/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

Many of the Exception subclasses' messages are uninformative. As an obvious
example, consider ArrayIndexOutOfBoundsException: the VM knows both what index
was passed, and the length of the array it was applied to, yet neither of these
pieces of information are shown. As a different example (different because the
exception is thrown explicitly from Java code) look at all the code in
java/awt/Color.java in, say, the testColorValueRange methods. It does all that
work, and still doesn't reveal the most salient point: what the given value
was. It reports which color components were affected (so we're grateful for
small mercies) but doesn't give us the vital clue to debugging the problem.

"yeah, sure," you say, "but that's what a debugger's for." true enough, but
most of the time, most people aren't running in debuggers. if debuggers were
better and faster, maybe most programmers could consider running in a debugger,
but at the moment they don't, and even if they did, customers wouldn't. so bug
reports would still arrive on their desks with these uninformative exception
messages.

i don't know how difficult it would be to improve the messages thrown by the VM
itself, but a lot of the weak errors in the library could easily be improved
with little effort. any and all improvements would be appreciated.


[I realize this isn't necessarily a 'bug', but it's both an RFE and
an ease-of-use issue, so I left that radio button as it was.]
(Review ID: 114974) 
======================================================================

Comments
EVALUATION Yes, we could do better. We could survey the uses of all exceptions in classes_lang, write new constructor methods to take the necessary appropriate arguments and produce more useful messages given that information. As this requires changes to the APIs, it should be considered for the next "upgrade" release (i.e. tiger). -- iag@sfbay 2001-11-1 Hmmm. My previous evaluation is correct, but describes a rather large problem which may not necessarily address a user's most pressing/annoying problem in a timely fashion. It would be much more useful for us to take reports of specific cases where we could improve our messages. ###@###.### 2005-07-11 18:37:36 GMT
11-07-2005

WORK AROUND Name: boT120536 Date: 01/11/2001 Run in a debugger. Or add System.err.println code and re-run. ======================================================================
19-09-2004