Is “Dying is Awesome” preferred?

Question

Recently I attended Jeffrey Richter\'s training courses about .NET. He mentions one strategy of coding \"Dying is awesome\". That is, don\'t write \"catch (Exception ex)\" e

Answer 1

Awesome answers here already, especially by Simucal. I just want to add a point:

Offensive programming is excellent for debugging. In my experience, "fail early, fail often" can be thought of as like setting traps for bugs in your code. When something goes awry--whether it's a memory leak, memory stomp, unexpected NULL, etc.--it's generally much easier to see the problem if the program fails immediately (with associated debugging data such as a callstack).

Defensive programming is excellent for production environments. Once your application has shipped, you may not want your end-users to ever see a nice little dialog saying "unhandled exception at foo()." That might be great if your app is in beta and you're still gathering debug info, but if you're shipping a stable app you might simply want to not bother the user with cryptic output in the rare case that something does fail.

Sometimes you can have it both ways. I've often wrote C code along the following lines:

void foo(char* data) {
    ASSERT(data);
    if (!data) { return; }
    // ... work with data
}

If this code is compiled in a test environment, the assert statement traps the error condition. If it is compiled in a production environment, the assert is removed by the pre-processor and foo() fails silently.

Exceptions are more expressive and flexible than asserts, and there are various ways to manage them such that an app fails early in a test environment and chugs along while logging errors in a production environment. Depending on the type of project, this sort of design may make sense for you.