The usual shorthand I use when there is no appropriate constructor is:

throw new InternalError(msg).initCause()

as initCause returns the original throwable. You may need to cast as well to get the right exception for the throws statement. Someone could really do with adding the appropriate constructors to all the API ones though; does this really need a JSR?

The message also annoys me as so many times people don’t include state information that would much cut down the debugging time e.g. “Invalid format” or “Incorrect pattern” — why not include the format or pattern in the string as well?!?

On the other hand, the standard Java library is full of inappropriate use of Exceptions that you might strongly argue actually don’t happen or only happen if you fail to do some elementary checking on your data. A run time exception is much more appropriate in such cases.

For example, I’ve encountered many times that I have to catch a UnsupportedEncodingException exception while I am pretty sure that a lack of support for utf-8 is pretty rare. So my code reads setEncoding(”utf-8″); and I am forced to deal with the possibility that utf-8 is somehow not supported.

I always log this type of exception at severe level because if it does happen something is seriously wrong with my code (e.g. typo in the utf-8). But it’s tedious to have to write this code.

Ismael

You’re obviously right that swallowing exceptions is very bad practice, but in most cases you can rethrow an exception with just one line instead of three by passing the cause in the constructor (which eliminates the need for the temporary variable). Of course this only works with exceptions that take a Throwable in the constructor, but this is quite common from my experience.

Regards,
Ismael