How can I create and enforce contracts for exceptions?

Question

I'm trying to convince my team lead to allow using exceptions in C++ instead of returning a bool isSuccessful or an enum with the error code. However, I can't counter this criticism of his.

Consider this library:

class OpenFileException() : public std::runtime_error {
}

void B();
void C();

/** Does blah and blah. */
void B() {
    // The developer of B() either forgot to handle C()'s exception or
    // chooses not to handle it and let it go up the stack.
    C();
};

/** Does blah blah.
 *
 * @raise OpenFileException When we failed to open the file. */
void C() {
    throw new OpenFileException();
};

1. Consider a developer calling the B() function. He checks its documentation and sees that it returns no exceptions, so he doesn't try to catch anything. This code could crash the program in production.

2. Consider a developer calling the C() function. He doesn't check the documentation so doesn't catch any exceptions. The call is unsafe and could crash the program in production.

But if we check for errors in this way:

void old_C(myenum &return_code);

A developer using that function will be warned by the compiler if he doesn't provide that argument, and he'd say "Aha, this returns an error code I must check for."

How can I use exceptions safely, so that there's some sort of contract?

Answer 1

This is a legitimate criticism of exceptions. They are often less visible than simple error handling such as returning a code. And there is no easy way to enforce a "contract". Part of the point is to enable you to let exceptions be caught at a higher level (if you have to catch every exception at every level, how different is it from returning an error code, anyway?). And this means that your code could be called by some other code that doesn't handle it appropriately.

Exceptions do have downsides; you have to make a case based on cost-benefit.
I found these two articles helpful: The necessity of exceptions and Everything wrong with exceptions. Also, this blog post offers opinions of many experts on exceptions, with a focus on C++. While expert opinion seems to lean in favor of exceptions, it is far from a clear consensus.

As for convincing your team lead, this might not be the right battle to pick. Especially not with legacy code. As noted in the second link above:

Exceptions cannot be propagated through any code which is not exception safe. The use of exceptions thus implies that all code in the project must be exception safe.

Adding a little bit of code which uses exceptions to a project that mainly does not is probably not going to be an improvement. Not using exceptions in otherwise well-written code is far from a catastrophic problem; it might not be a problem at all, depending on the application and which expert you ask. You have to pick your battles.

This is probably not an argument I would spend effort on--at least not until a new project is started. And even if you have a new project, is it going to use or be used by any legacy code?

Answer 2

There are literally whole books written on this subject, so any answer will be a summary at best. Here are some of the important points I think are worth making, based on your question. It's not an exhaustive list.

---

Exceptions are intended NOT to be caught all over the place.

As long as there is a general exception handler in the main loop - depending on the type of application (web server, local service, command line utility ...) - you usually have all the exception handlers you need.

In my code, there are only a few catch statements - if any at all - outside the main loop. And that seems to be the common approach in modern C++.

---

Exceptions and return codes are not mutually exclusive.

You should not make this an all-or-nothing approach. Exceptions should be used for exceptional situations. Things like "Config file not found," "Disk Full" or anything else that cannot be handled locally.

Common failures, like checking whether a filename provided by the user is valid, is not an use case for exceptions; Use a return value in those cases instead.

As you see from the above examples, "file not found" can be either an exception or a return code, depending on the use case: "is part of the installation" versus "user can make a typo."

So there is no absolute rule. A rough guideline is: if it can be handled locally, make it a return value; if you cannot handle it locally, throw an exception.

---

Static checking of exceptions is not useful.

As exceptions are not to be handled locally anyway, it usually isn't important which exceptions can be thrown. The only useful information is whether any exception can be thrown.

Java has static checking, but it usually is considered a failed experiment, and most languages since - notably C# - don't have that type of static checking. This is a good read about the reasons why C# doesn't have it.

For those reasons, C++ has deprecated its throw(exceptionA, exceptionB) in favor of noexcept(true). The default is that a function can throw, so programmers should expect that unless the documentation explicitly promises otherwise.

---

Writing exception safe code has nothing to do with writing exception handlers.

I would rather say that writing exception safe code is all about how to avoid writing exception handlers!

Most of the best practices intend to reduce the number of exception handlers. Writing code once and automatically invoke it - e.g. through RAII - results in less bugs than copy-pasting the same code all over the place.

Answer 3

C++ programmers don't look for exception specifications. They look for exception guarantees.

Suppose a piece of code did throw an exception. What assumptions can the programmer make that will still be valid? From the way the code is written, what does the code guarantee in the aftermath of an exception?

Or is it possible that a certain piece of code can guarantee never to throw (i.e. nothing short of the OS process being terminated)?

The word "roll back" occurs frequently in discussions about exceptions. Being able to roll back to a valid state (that is explicitly documented) is an example of exception guarantee. If there is no exception guarantee, a program should be terminating on the spot because it is not even guaranteed that any code it executes thereafter will work as intended - say, if memory has corrupted, any further operation is technically undefined behavior.

Various C++ programming techniques promote exception guarantees. RAII (scope-based resource management) provides a mechanism to execute cleanup code and ensure that resources are released in both normal cases and exceptional cases. Making a copy of data before performing modifications on objects allow one to restore that object's state if the operation fails. And so on.

The answers to this StackOverflow question gives a glimpse to the great lengths C++ programmers go to understand all of the possible failure modes that could happen to their code and try to guard the validity of program state despite failures. Line-by-line analysis of C++ code becomes a habit.

When developing in C++ (for production use), one cannot afford to gloss over the details. Also, binary blob (non-open-source) is the bane of C++ programmers. If I have to call some binary blob, and the blob fails, then reverse engineering is what a C++ programmer would do next.

Reference: http://en.cppreference.com/w/cpp/language/exceptions#Exception_safety - see under Exception Safety.

C++ had a failed attempt at implementing exception specifications. Later analysis in other languages says that exception specifications simply aren't practical.

Why it is a failed attempt: to enforce it strictly, it has to be part of the type system. But it isn't. The compiler does not check for exception specification.

Why C++ chose that, and why experiences from other languages (Java) proves that exception specification is moot: As one modify the implementation of a function (for example, it needs to make a call to a different function that may throw a new kind of exception), a strict exception specification enforcement means you have to update that specification as well. This propagates - you may end up having to update the exception specifications for dozens or hundreds of functions for what is a simple change. Things get worse for abstract base classes (the C++ equivalent of interfaces). If exception specification is enforced on interfaces, implementations of interfaces will not be allowed to call functions that throw different types of exceptions.

Reference: http://www.gotw.ca/publications/mill22.htm

Starting with C++17, the [[nodiscard]] attribute can be used on function return values (see: https://stackoverflow.com/questions/39327028/can-a-c-function-be-declared-such-that-the-return-value-cannot-be-ignored).

So if I make a code change and that introduces a new kind of failure condition (i.e. a new type of exception), is it a breaking change? Should it have compelled the caller to update the code, or at least be warned about the change?

If you accept the arguments that C++ programmers look for exception guarantees instead of exception specifications, then the answer is that if the new kind of failure condition doesn't break any of the exception guarantees the code previously promises, it is not a breaking change.

Answer 4

Consider a developer calling the C() function. He doesn't check the documentation so doesn't catch any exceptions. The call is unsafe

It's totally safe. He doesn't need to catch exceptions in every place, he can just throw a try/catch in a place where he can actually do something useful about it. It's only unsafe if he allows it to leak out of a thread, but it's typically not hard to prevent that from happening.

Answer 5

If you are building a critical system, consider following your team lead's advice and not use exceptions. This is AV Rule 208 in Lockheed Martin's Joint Strike Fighter Air Vehicle C++ Coding Standards. On the other hand, MISRA C++ guidelines have very specific rules regarding when exceptions can and cannot be used if you are building a MISRA-compliant software system.

If you are building critical systems, chances are you are also running static analysis tools. Many static analysis tools will warn if you do not check the return value of a method, making cases of missing error handling readily apparent. To the best of my knowledge, similar tool support for detecting proper exception handling is not as strong.

Ultimately, I would argue that design by contract and defensive programming, coupled with static analysis is safer for critical software systems than exceptions.