Why We Should Analyze Exceptions

Now that we know exceptions in the logs aren't always a bad sign, does that mean we should leave them unhandled? Generally my point of view is that the logs files should contain as few exceptions as possible. An occasional exception means that something exceptional has happened and we should investigate, but if there are similar exceptions over a period of time that means that the event is not exceptional anymore and is something commonplace. Therefore the application needs to be changed so that handling such events becomes part of the normal program flow rather than an exceptional event.

Going back to my file reader example, the developer initially thought that there might be one possible error that he needs to check for and that was a missing parameter. So he built the check into the application logic:

out.println(readFile(fileName)); } else {

out.println("No file specified");

That's a good strategy, as it may sometimes happen that the external references do not specify any file name, but the application happily handles the situation.

Now let's pretend for a moment that this has been running for a long time and no one has reported any issues. But one day you decided to have a look at the application log file and noticed some unusual exception stack traces that have never been logged before:

Jan 18, 2010 8:08:35 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet FileServer threw exception java.io.FileNotFoundException: /etc/this_does_not_exist_2 (No such file or directory)

at java.io.FileInputStream.open(Native Method)

This indicates that users are trying to reach a file that does not exist. You know that the only link to your web service is from another page, so you go and fix it. How do you prevent this from happening again? There's nothing wrong with your application, but you might want to check and improve the process of adding the new links to the external page so that it only points to the files that do exist. Whether to build in a case for handling files that do not exist is entirely up to you, as there are no hard rules defined about when and what should be handled in the application logic. My view is that if the exception is highly unlikely to happen, it's best to keep the application logic as simple as possible. Now some time later you encounter yet another exception:

Jan 18, 2010 8:07:59 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet FileServer threw exception java.io.FileNotFoundException: /etc/shadow (Permission denied) at java.io.FileInputStream.open(Native Method)

This time it's indicating that the file is present but with the wrong permissions. Again it's time to investigate why this is happening and fix the root cause of the issue, which isn't always the application but might well be something external to it. In this situation a new system administrator changed the file permissions, and that broke the application.

As you can see from this simple real-life scenario, exceptions in the application log files do not necessarily mean issues with the application that is generating them. To find the root cause of the issues that are either directly or indirectly indicated by the exception logs you as a system administrator need to know as much as possible about the various indicators. Having exception stack tracing is very useful, but you also want to know when the exception first started to appear in the log files. What is the extent of the problem—how many of the exceptions are you getting? If you are receiving a large number of them it is probably not really an exceptional situation, and the application needs to be modified to handle it as part of the application logic.

Was this article helpful?

0 0

Post a comment