This issue applies accross entire jdk sources. The exceptions thrown from jdk sources usually don't provide enough information to fix the issue, just by reading the message and looking at the stack trace. Developer needs to usually manage to reproduce the issue, even for very simple cases, just to find out some values, which should have been provided in the exception message.
This slows donwn her developement, and makes the java less efficient tool.

There are typically excecptions with very poor description messages like:
- "illegal value".. without providing expected value, and the actual value;
- "illegal state of component".... but no information about which component instance, its name, display name,...
etc.


There should be created and strictly folowed rules about what a message of an exception should provide. Something like:
1) Each exception has to provide info about the place where the exception occured.. i.e. the actual instance of an object (class), and its important values; if the class properly overrides toString() method, that usage should be OK;
2) Provide as much as possible available information, relevant to the state which led to the exceptions. I.e. properties which have wrong values, what are expected values; other important values which could affect the state... etc.

There should also folowed:
- Dont use Errors instead of Exceptions, Errors are supposed to refer problems of VM. Not keeping this prevents nice advanced exception handling in larger app's. 
- Dont create and throw exceptions with no messages. This is obvious from the above, at least the 1) has to be used.

###@###.### 2004-06-01