How to Rethrow an Exception Without Wrapping them - Java Wiki

Nicely said at How to Rethrow an Exception Without Wrapping them

Some do's and don't's with exceptions

1. Unless you have a very good reason to catch an exception, don't catch it.

2. If you can correct the problem implied by the exception. eat the exception, because you fixed it. However there are some exceptions that it is unwise to catch.

3. If you can provide additional information about the exception. catch the exception, and re-throw it as an inner exception with more information. This is a very good reason to catch an exception, but note that we are still re-throwing it.

4. Always try to catch specific exceptions. Avoid catching System.Exception whenever possible.

Comment regards to "An importance of wrapping variables"

The comment was made regards to the blog posting An importance of wrapping variables. A useful feature to add to any logging tool is to allow the formatting of the log message. For example,

File file = ...
...
logger.info( "unable to open file: file-name={0}", file );

Doing this has three key advantages. The first is that the ease of adding relevant data to the message is trivial. This then encourages messages that truly aid monitoring and debugging. The second is that there is a very low performance cost to logging in that if the message is never used (due to the log level) then the only cost to making the call is loading and unloading the stack.

The second advantage becomes significant for debugging messages. For example, the debug logger call

logger.debug("{0} moving towards {1}", a, b );

is a far less costly to ignore than is

logger.debug( a + " moving towards " + b );

And especially so in a tight loop. One can argue that you can always check the debug level before making a debug call. In practice, however, this tends to not to be done and instead the useful debug message is never written.

The third advantage is that it is trivial in the logger implementation to both quote and escape the message's parameters. My implementation passes them through a JSON converter so that I can also see the internals of the parameter's values.