Question

I do not really use any try/catches in my code ever but I’m trying to break that habit and now get in to using exceptions.

I figure the most important place to have it in my application would be reading a file and I’m trying to implement that now but I’m unsure of the “best-practices” for doing so. Currently I’m doing something like this:

private void Parse(XDocument xReader)
{
    IEnumerable<XElement> person = xReader.Descendants("Person").Elements();

    foreach (XElement e in person)
        personDic[e.Name.ToString()] = e.Value;

    if (personDic["Name"] == null || personDic["Job"] == null || personDic["HairColor"] == null)
        throw new KeyNotFoundException("Person element not found.");
}

But I am unsure if this is correct. I have this for handling it:

try
{
    personsReader.Read(filename, persons);
}
catch (KeyNotFoundException e)
{
    MessageBox.Show(e.Message);

    return;
}

// Do stuff after reading in the file..

However when showing e.Message it just shows the generic KeyNotFoundException error message and not by custom error message. Also I’m not sure if in general I am going about this whole “exception handling stuff” properly. I do return in the catch because if the file is not read successfully obviously I just want to pretend like the user never tried to open a file and let him try again with another file.

Am I doing this properly? Again I am fairly new to using exceptions and I want to make it sure I got it down right before continuing on and applying this to the rest of my program.

Also, why do people say not to do catch (Exception e)? It seems like in this case I would want to do that because regardless of what error occurs when reading in a file, if there is an error, I want to stop reading the file, display the error message, and return. Wouldn’t that always be the case? I can understand not wanting to handle Exception e if you would want to handle something differently based on the exception but in this case wouldn’t I want to just handle the base exception class in case anything goes wrong?

Answer 1

You should catch exceptions when you can handle the condition and do something useful. Otherwise you should let it bubble up the call stack and perhaps someone above you can handle it. Some apps have unhandled exception handlers to handle it at the outer most layer but in general, unless you know you have some useful way to handle it, let it go.

In your case, you’re handling not being able to read a resource and informing the user. You’re handling it. Concerning the generic exception, one thing you can do is catch and re-throw a better exception. If you do that, make sure you incude the root cause exception as the inner exception. You can also trace or log the details if appropriate.

throw new MyGoodExceptionType ("Could not read file", e);  // e is caught inner root cause.

Now the UI shows a good error and perhaps the inner root cause is in a log etc…

Some typical mistakes:

• Handling exceptions deep in the stack in a generic library method: Remember that a common library function may get called in many different code paths. You likely don’t have the context whether it should be handled and whether it’s appropriate to handle it. the caller higher in the stack likely has context and knows whether it’s safe to handle. Typically that means higher layers of code decide to handle. In lower layers, typically you let them flow.

• Swallowing Exception: Some code catches exceptions (especially lower in the stack) and then the root condition just evaporates making it maddening to debug. Once agan, if you can handle it, do so. If not, let it go.

• Exceptions should be exceptional: Don’t use excpetions for flow control. For example, if you’re reading a resource, don’t try and read and then catch the exception and make a decision point. Instead, call ifexists, check bool and make decisions in your code. this especially helps when you set the debugger to break on exceptions. You should be able to run clean and if the debugger breaks, it should be a real issue. Having the debugger break constantly when debugging is problematic. I personally like throwing exceptions very rarely and always try to avoid for flow control.

Hope that helps.