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.
