errors and exceptions

Let’s dive in and take a look at some common and not-so-common exception handling arrangements.

Everyone should be familiar with the standard try..catch..finally construct:

try {
    //this code will run only until an exception is thrown
}
catch {
    //this code will run only IF and exception is thrown
}
finally {
    //this code will run always AFTER the try and/or catch blocks have been executed
}

Here is a less common arrangement. When might this be appropriate to use?

try {
    try {
    }
    catch {
    }
}
finally {
}

Now let’s look at some concrete examples. Consider this code snippet:

Read More »Order of Operations in nested try..catch..finally

There has been a lot of discussion over the years about when and how to use exception throwing and handling. The general consensus seems to shift every once in a while. The performance of exceptions is not the primary purpose of this article, but I felt the need to discuss it in order to truly address the role of exceptions in software troubleshooting.

Exceptions are Expensive, like Store Brand is Cheap

Maybe the best way to breach the topic of exception performance is to simply give you a short list of axioms that I believe to be true.

1. Exceptions are expensive

It has been proven many times that there is additional cost associated with constructing and throwing an exception. This seems to be exaggerated in managed applications (.NET, Java, etc.). That being said, this extra “cost” of constructing and throwing an exception would only be noticeable in time-critical real-time systems, or if they are used excessively. That brings me to my next axiom…

Read More »Exceptional Introduction