Programming with Exceptions

While exceptions are now virtually ubiquitous in programming languages, they are not always used effectively in practice. This is understandable given the fact that popular C++ and Java libraries don't always set a good example.

Early in my programming career I didn't see the value of exceptions. Having worked with C style APIs, I found the C++ try/catch construct to be cumbersome. It seemed like a long winded way to check return codes. Consider:

Example 1 - Handling Exceptions inside a Function

bool log(const char* msg) {
    bool bReturn = true;
    try {
        if (!mFile.isOpen())
            mFile.open(gLogFile);

        mFile.write(msg);
    }
    catch(FileError& e) {
        std::cerr << "Failed to write to log file: " << e.what() << std::endl;
        bReturn = false;
    }
    return bReturn;
}

It turns out that to see the payoff, you have to look at the example in a larger context. For example, consider all of the places a log() function is called throughout a small program:

Example 2 - Error Handling via Return Codes

bool subTask1() {
    bool bResult = log("subtask 1");
    if (bResult) {
        bResult = callAPIOne();
        if (!bResult)
            std::cout << "api 1 failed" << std::endl;
        }
    return bResult;
}

bool subTask2() {
    bool bResult = log("subtask 2");
    if (bResult) {
        bResult = callAPITwo();
        if (!bResult)
            std::cout << "api 2 failed" << std::endl;
        }
    return bResult;
}

bool task1() {
    bool bResult = log("task 1");
    if (bResult)
        bResult = subTask1();

    return bResult;
}

bool task2() {
    bool bResult = log("task 2");
    if (bResult)
        bResult = subTask2();

    return bResult;
}

int main() {
    bool bResult = task1();
    if (bResult)
        bResult = task2();

    return bResult ? EXIT_SUCCESS : EXIT_FAILURE;
}

Example 3 - Using Exceptions instead of Return Codes

void log(const char* msg) {
    if (!mFile.isOpen())
        mFile.open(gLogFile);

    mFile.write(msg);
}

void subTask1() {
    try {
        log("subtask 1");
    }
    catch(exception& e) {
        throw exception("subtask1 failed");
    }

    if (!callAPIOne())
        throw exception("api 1 failed");
}

void subTask2() {
    try {
        log("subtask 2");
    }
    catch(exception& e) {
        throw exception("subtask2 failed");
    }

    if (!callAPITwo())
        throw exception("api 2 failed");
}

void task1() {
   try {
       log("task 1");
       subTask1();
   }
   catch(exception& e) {
       throw exception("task 1 failed");
   }
}

void task2() {
   try {
       log("task 2");
       subTask2();
   }
   catch(exception& e) {
       throw exception("task 2 failed");
   }
}

int main() {
    int result = EXIT_SUCCESS;
    try {
        task1();
        task2();
    }
    catch(exception& e) {
        std::cerr << "program failed: " << e.what() << std::endl;
        result = EXIT_FAILIURE;
    }
    return result;
}

Now comes the key observation, however: with exceptions, we don't need to have error handling at every level:

Example 4 - Using Exceptions with Minimal Catch Blocks

void log(const char* msg) {
    if (!mFile.isOpen())
        mFile.open(gLogFile);

    mFile.write(msg);
}

void subTask1() {
    log("subtask 1");
    if (!callAPIOne())
        throw exception("api 1 failed");
}

void subTask2() {
    log("subtask 2");
    if (!callAPITwo())
        throw exception("api 2 failed");
}

void task1() {
   log("task 1");
   subTask1();
}

void task2() {
   log("task 2");
   subTask2();
}

int main() {
    int result = EXIT_SUCCESS;
    try {
       task1();
       task2();
    }
    catch(exception& e) {
       std::cerr << "program failed: " << e.what() << std::endl;
       result = EXIT_FAILIURE;
    }
    return result;
}

Sources of Misunderstanding

Unfortunately it seems that some Java language and library designers fell into the trap of treating exceptions as if they are error codes as well. In fact I think this has been a major source of misunderstanding for programmers. Java provides "checked" exceptions, which actually require that they are accounted for at each level. There are a couple of ways around this - functions can declare "throws Exception", or APIs can be written to throw "unchecked" exceptions - but unfortunately the Java libraries themselves are littered with examples of checked exceptions, with error checking at every level.

Conclusion

If you follow good coding practices with regards to separation of responsibilities, you will find that your code has many levels of function calls. There is very often little to gain by including error handling code inside intermediate functions, and in fact doing so without being careful can result not only in a loss of clarity but in a loss of valuable error details. (In fact, take another look at Example 3 above - there are several places where error detail is "swallowed", to demonstrate the point).

So the guideline I suggest for exceptions is to use catch blocks only when necessary. It maximizes the readibility of the code, keeping it focused on the task at hand, instead of on those cases where something has gone wrong (i.e. the "exceptional" cases!).

Note that while the issues I have discussed here apply generally to most any language which supports exceptions, there are some specific issues to be aware of when working with exceptions in C++. I will discuss C++ exception specifics in a future article.

Posted by Steve Hutton on Thu, 23 Nov 2006 05:39:00 +1600 [Permalink] [More on C++]

Previous: Python Web Frameworks

Related Links:

Post a comment