Having error codes option in C++ library for performance

Question

I have written an open source and cross-platform C++ File Library which have exception and error codes. Exceptions can be disabled when the program is running. In that case, the user have to check the error codes. Of course, when exception throwing is enabled, error code won't be returned because exception is thrown before the called function returns.

Currently, exceptions still could be thrown when disabled (bug). I'll fix that soon. Someone comment to me that it is considered bad design to have both exception and error codes. I agree with him and I am about to remove the error codes and have library throw custom derived exceptions with more error information.

But I hesitate. I like to have this hybrid approach for performance reasons. This is what I am thinking of doing: keeping exception throwing and error codes but exception throwing is disabled through macro at compile time instead of runtime.

If user define the following in a common config file

#define ELMAX_EXCEPTION 1

The follow code

int Write(std::wstring str) ELMAX_THROW_OR_NOT;

would expand to either of the 2.

// under C++11 compiler
int Write(std::wstring str) noexcept;

// under C++98 compiler
int Write(std::wstring str) throw();

If ELMAX_EXCEPTION is not defined or is zero, the macro would expand to nothing.

int Write(std::wstring) ;

The reason I want to do this, is for library user who wants the performance gain of not having the compiler generating the stack unwinding code (for exception) and compiler can better optimize such functions. My C++ file library is using C file API and the only thing which could throw exception is new keyword, which I intend to add nothrow. The UTF-8 code can also throw exceptions (need to be changed too)

char *parr = new (nothrow) char[num];

if(parr==NULL)
    // handle it either through error code or throw exception (if enabled)

Please kindly advise if I should have a pure exception approach or a hybrid approach (as mentioned), for my library errors?

Answer 1

The cost of throwing an exception is negligible compared to writing to a disk. In addition, return codes are more expensive, not less. Finally, nobody is going to care how fast your library is when they can't make their program have the correct semantics because their teammate who just joined the company forgot to check a return code.

The only safe return code is the one that the user can safely ignore.

Answer 2

The choice between exceptions and error codes should not be a global one, but rather based on how exceptional the error condition is with a normal usage of the library.

• Error codes should be used for situations that are erroneous but that can easily occur with a normal usage of the library. For example, failure to open a file or failure to read an integer at the current position.
• Exceptions should be used to report serious problems that should not occur with normal usage of the library and that the immediate caller is unlikely to be able to recover from. Examples of these are memory exhaustion or hard errors reported by the underlying filesystem (e.g. disk full).

And for I/O libraries, you can also consider using a delayed error reporting mechanism. Instead of having each function return an error code (which has to be checked by the caller), the error code is stored internally. Subsequent calls do nothing if they determine an earlier call resulted in an error and the user of the library has to check (at a convenient point) if an error has occurred in the preceding set of calls. This is the default mode of operation for the standard C++ I/O streams.

Answer 3

If you have good use cases for both, consider splitting your library into two or three classes:

• The core, which contains the code that does the work and is able to return enough information on failure to produce an error code or an exception.
• A wrapper class that calls the core's methods and throws exceptions on failure. The trade-off here is that exceptions thrown won't show exactly where in the core class a failure occurred. This may not be an issue depending on the complexity of the core's methods.
• A wrapper class that calls the core's methods and returns error codes on failure. If appropriate, the core class could be used directly, eliminating the need to have a non-throwing wrapper.

Whatever you do, don't change the library's behavior using the preprocessor. Doing so will change the method prototypes:

class Foo {
  #ifdef NO_EXCEPTIONS
    StatusType bar() { ... }
  #else
    void bar() { ... }
  #endif
};

The first time a class expecting the exception-throwing behavior #includes another's header that has the NO_EXCEPTIONS macro set, you'll have uncompilable code because there will be code present that expects Foo to be prototyped two different ways.

Answer 4

Its up to you, but error codes are easier to document and handle within a library like this. Exceptions can be a performance killer, if you're using them for all possible errors then you might end up with them being used for program flow - and that is very bad. In addition, I'd be worried that someone is calling your library from an app that has exception handling turned off.

Generally speaking, if you're writing a completely sealed-off component, you shouldn't be throwing exceptions outside it unless they are definitely documented as things to expect. No-one wants to know about the internals of your component so all exceptions you throw internally should be caught and then (where applicable) presented to the user as a defined error case. In most cases, returning this information as an error code is the simplest, easiest and safest approach.

The reason here is that you can throw whatever exception you like, or the system can do so for you, and the user of your component can do nothing with it. At least with error codes, you're not going to let unhandled exceptions propagate through to the user.

You must not allow exceptions to return from your component if they're "normal" errors. People say that exceptions should be for exceptional situations and they're right - once you start returning "end of file" exceptions, the user will have to wrap every last one of your method calls in an try block - which makes for really messy code. If you use exceptions, the user should be able to call your functions and never put a try block anywhere, if nothing goes wrong there won't be a problem. If you can't achieve this then the user's code will have to be littered with exception handlers for all the cases where he thinks you might throw one.

A hybrid approach can work though, error codes for most things with exceptions for all unexpected problems, but if you're doing that, you might as well stick with just error codes at the boundaries of your library.