All About Exceptions: What to do and Where to log?

Question

My question actually comes in two parts hence the ambiguous title.

Part One

As far as I'm aware, you should never swallow an exception. Not even logging it and forgetting about. In general cases, I try to solve an exception and retry the code - for example, let's say I get a FileNotFound exception.

I prompt the user to check the file exists and try again, offering another file chooser dialog and hoping for the best. Failing attempting to solve the problem I end up notifying the user and logging the exception. I've been told that this isn't the correct thing to do in a catch block, so am I doing it right by attempting to solve the issue?

I can't think what else I should do. I suspect I'm being fed misinformation - I'm a gullable soul.

Part Two

Creating a log in my program directory to log an exception is fine I think, but again I'm being told that exceptions should be written to the windows eventlog. Is this correct? Under what circumstances should you write to the event log?

Silly questions need silly answers.

Edit: There is no context to this question other than a general vague domain. My friend and I were blabbering about the right things to do in particular circumstances.

Answer 1

Here are some best-practices for exception handling.

http://stackoverflow.com/questions/409563/best-practices-for-exception-management-in-java-or-c

Answer 2

Part One

Generally, you don't want to have exception generating behaviour in a catch block.

try
{
   ExceptionThrowingMethod();
}
Catch(Exception ex)
{
   //Log It
   //Try Again
   ExceptionThrowingMethod();
}

Clearly, the second exception will be uncaught, and you generally don't want to have try-catches nested within a catch-block. Generally your catch block should

1. Log the error. Always. Even if you set it to your lowest logging level, and never read those logs.
2. Determine whether your current state is recoverable. (Are the right variables set or null? Did it break during a critical function, or between them?)
3. If you can recover, set some variables that indicate 'try-again', and allow execution to flow OUT of the catch-block. If you cannot recover, try to add some context, and then re-throw the error.

Catch blocks are for error recovery, not for regular execution. So, even through FileNotFound is an exceptional occurrence, prompting the user to try and locate their file is not, and so it should happen in its own try-catch (or loop back to the initial one).

Part Two

Generally, I would prefer writing logs to their own directory, because that way I know exactly where they are, and I also know that everything in the log is relevant. If your application is a critical application, (I.E. a service that needs to be running for a framework to work) then you might consider logging to the eventviewer. There's also the everybody wins method of logging to both. You could have thorough logs in your program directory, and log any critical errors to your event viewer.

Without knowing what reason you were given to log to the event viewer, I can't tell whether or not it's good advice.

Answer 3

First off if you ever hear the word Never your ears should perk up... That is why they are called "Best Practices" and not "Rules written in Stone that you must follow..."

here is Microsoft's Exception Handling Best Practices Guide

And there are going to be plenty others...

It really boils down to you as a developer, your teams standards, your customer, etc. What do you want the application to do?

Question 1: Do you want the application to be able to continue on if an exception it thrown? Then I would "swallow" the exception.

Question 2: Is there a benefit to logging a particular exception to the event log or is it just going to bloat it with useless information, You may want to write every exception to the log during development and testing and have verbose information and then in production streamline it... I hope I have answered your question even though there really isn't an generic one...

I would say you should have some general guidelines and then if you have more specific situations then it would be a good time to re-post to this site and get some feedback from people that have tried different routes and can speak to the pros and cons.

Answer 4

The Code Analysis Team Blog is a great place to start on this topic. Also look at

Martin Fowler - Fail Fast

MSDN on Exception Handling

Checked vs Unchecked Exceptions

The second part of your question really depends. In many applications where you need central exception reporting, writing to the event log is a good idea. There are plenty of other cases where it would be a waste of time to do that, you'll have to use your own judgment on that.

Answer 5

I found this to answer part two of my question and it seems from a bit of further research that logging exceptions to the event log isn't a mysterious and dark practice. Thanks for your help everyone.