How assertive should I be in handling exceptions in objects?

Question

I have been writing in C# 4.0 a lot lately and trying to write as lean as possible. As such, I have not been using the classic try/catch blocks and using statements as often.

I understand the general function of .Net's garbage collection and exception handling - I want to bulletproof my code and be efficient with objects, but I am trying to achieve this with the minimum amount of 'extra code' (since 'bloat' pissed people off).

And to be clear, I understand using() is fundamental for relinquishing resources to handles and other code and its relationship to the IDisposable interface.

But I am trying to get a better grip about how assertive a programmer should be in exception handling objects.

Are there key places in code you'd say try/catch blocks and/or using statements are inarguably necessary? Within the contexts of garbage collection and exception handling, what common-use objects/scenarios would you recommend explicit attention?

Should you simply make a catch block for every possible exception an object might through? How deep should they be nested? Are there steps I can take to proactively collect garbage (for example, to combat the example in comments of waiting for Dispose() to be called)?

Answer 1

using is not a "bloat", it's necessary to free resources wrapped into IDisposable objects. using is compiled into try...finally, with a call to the Dispose method in the finally section. For example, when StreamReader and StreamWriter are used to read and write files, respectively - their Dispose method automatically closes the file. Another example is SqlConnection - its Dispose method must be called to close the connection, and a using statement is a clean way to do it.

Regarding try...catch, their use in .NET does not differ from exception handling in C++ or Java. Exception handling decreases performance a bit, but that whether this is significant can only be determined by profiling the code. Exception handling must not be used for changing control flow, and it"s also not wise to use it to swallow exceptions. These and other important properties of exception handling can be found in OOP/C++/Java/... textbooks.

Answer 2

try/finally and using are almost totally orthogonal concerns to memory leaks. You should use using or try/finally when you have non-memory resources, like a lock, a handle, or a connection, and you need to make sure those are cleaned up.

There are very few or no common cases in .NET where you need to pay explicit attention to avoiding memory leaks. The only way you'll wind up with a memory leak if if you're retaining a reference to something old and you don't realize it; there are a few ways this can happen, like if that thing has an event you didn't unsubscribe from. But there's nothing mysterious.

Answer 3

using is only allowed by the language for situations where you should almost certainly be doing it - that is, classes which implement IDisposable. You're free to write code that implements IDisposable needlessly if you really want to, but almost all libraries will only do it for a reason - because the object needs to be cleaned up. You can write the dispose logic yourself if you want to, but there is really no benefit because using does exactly the same thing, it's just clearer.

Your definition of 'bloat' is an interesting one. While I understand that boring plumbing code is undesirable, that just makes it a candidate for walling up in a base class, not excluding it altogether. If boring code is proliferating, it can be an indication that you are violating DRY and should aim to refactor so that you specify the behaviour only once for everything that needs it.

Answer 4

Every exception gets handled. You just get to choose if it kills your program or not, and if not, what you want to do after that. I regularly write code that throws exceptions all up and down the stack, catches the ones that it wants to recover from, and has a simple main method:

public static int main(string args[])
{
    try {
        DoSomethingUseful(args);
        return 0;
    } catch (Exception e) {
        Console.Write("Uncaught exception percolated to top level: " + e);
    }
    return 1;
}

Answer 5

Nested levels of try catch must be avoided if all they do is nothing but log the exceptions. If object supports IDisposable then it must be wrapped in using block.

Exceptions must be caught mostly on root entry points, instead catching and rethrowing at various levels. It just makes code little more complex to analyze stack traces.

Try-finally must be used only if resource object does not support IDisposable, or to turn some Boolean switches or to synchronize threads.

Don't ever use exceptions as part of logic, for example if I catch exception a then follow method b else follow method c, something like that. Other example include using exception in place of return type. Imagin you have ValidateUserPass method that returns void and throws exception instead of returning proper result. I know it is argueous but invalid logic is a user error and exception should mostly be used for system or network failure.

Do not throw generic exception Exception, but use proper encapsulated class for it.

At root level, catch all exceptions because it must be logged, and at intermediate level, do not catch exception unless you want to continue the logic in alternate way.

For example,

 try{
     connectToDevice()
     return;
 }catch(IOException ex){

 }
 connectToDatabase();

Here if I will catch all exception then I will eat up or catch wrong exception if I will put all in try block. Here in case my device connection fails I want to connect to database and work in offline mode. This is part of the logic only if device fails to connect.

But if user has entered a null as an address string, that should not be caught here because it is not an error to connecting device. My null pointer exception should be caught at root level, and not in this code.

For logging, catch all exceptions.

For alternative branch of execution, catch only one type of exception.

Answer 6

To address the part of your question about what exceptions you should catch, have a look at this article:

How to Design Exception Hierarchies

Despite the title, it's very useful in understanding the different types of exceptions. There are three types, and they should be handled in three different ways:

• Usage error. This is due to an error in coding - fix your code.
• Logical error. An unavoidable condition, such as file not found - handle the exception.
• System failure. A system error such as out of memory - shut down the program.

(File not found is unavoidable because even if you call File.Exists(), it's possible someone could delete the file just before you access it. So to really be correct, you still need to handle it.)

The only case where you definitely need try/catch blocks is for logical errors. In those cases, you can't guarantee avoiding the exception, so you need to handle it.