I would say that only one out of a million exceptions thrown in an application actually makes it to a log file – unless you run your application in verbose logging mode – Do you agree? No? Here is why I think that is: Because most exceptions are handled by your code or by the frameworks your app uses. Here is a chart from an enterprise application showing that there are about 4000x more custom application exception objects thrown than important log messages written.
So why worry about these exceptions that nobody cares to write to a log file? Two reasons:
- They are typically thrown for a good reason and therefore indicate a problem, e.g: configuration issues in frameworks or runtime problems
- Every Exception object is a potential performance problem because it means the JVM needs to allocate memory, get the stack trace and dispose the object soon after
Reason #1: Configuration Problems
The following shows a transaction where the method getImagePath makes a web service call to a backend server using HttpClient. getImagePath uses a an HTTP Endpoint URL. The Web Service however only supports HTTPS (SSL). The web service call therefore fails with an SSLException. getImagePath retries 3 times until it gives up and just returns a default value to the caller. No log entry written, no exception thrown to the caller, everything seems OK to the outside world even though we have a severe impact on an end user who is waiting longer than necessary for an image that he doesn’t get to see: