Grumble: exception messages

Grumble time! ;D

[quote]java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
[/quote]
Why, oh why can’t the JVM engineers throw useful messages with their exceptions? How hard would it have been to give the index that was duff, along with the length of the array?

But no! When a developer gets an exception like this, they need to locate the offending code and look at it real hard, or put in a load of debug messages and try to replicate the exact conditions that caused the exception in the first place - just to find out what actually went wrong. Then they have to fix it.

Related to this grumble, why do some exception subclasses not support a message at all? Take BufferOverflowException - the NIO people may not have found use for a message in today’s implementation of the NIO library, but there’s really no reason to go out of their way to make the class useless for everyone else, is there?

And maybe if they looked hard enough, they’d decide that sometimes including a message with a thrown BufferOverflowException might actually be useful

Chuckle. It took us not-very-long-at-all to want to throw a BOE with a message.

Depending upon how you interpret the crap API docs, you could take it that this is NOT a BOE, but actually a “BufferPutOverflowException”, reserving a common name solely for the usage of a very uncommon error.

In the end, rather than risk the ambiguity of the docs, we just made a ReadBufferOverflowException, WriteBufferOverflowException, etc.

But yes, I think Sun’s libraries would significantly benefit from someone allowing them to / teaching them how to use some not-so-uncommon automated test-tools, including code-lint type stuff: it’s easy to auto-check to see whether every exception has a constructor supporting a message, for instance.