Which is more memory/performance efficient for static error strings, or are there alternatives?

Question

I would like an opinion on what is the best way to handle static error strings in C++. I am currently using a number of constant char pointers, but they get unwieldy, and they are scatter every where in my code. Also should I be using static constant char pointers for these strings?

I was thinking about defines, hash tables, and INI files using the SimpleIni class for cross-platform compatibility. The project is an always running web server.

I would like to use error numbers or names to refer to them logically.

I am using the global space and methods contained in namespaced classes if that helps. The code is exported to C because of the environment if that helps as well.

Thanks

Answer 1

First of all, you can check other related questions on stackoverflow. Here you have some:

• C++ Error Handling -- Good Sources of Example Code?
• Exceptions and error codes: mixing them the right way

Then have a look at this great tutorial on error handling (it is a five parts tutorial, but you can access all of them from that link). This is especially interesting if you are using C++11, since it provides many more features for error handling. Alternatively you could use boost if you cannot use C++11.

You also need to consider whether you want to include support for localization. If your application may present messages to the users in different languages, it is better if you include that requirement from the very beginning in the error management too. You can check Boost.Locale for that, for instance.

Answer 2

There are several things in tension here, so let me please enumerate them:

• centralization / modularity: it is normal to think about centralizing things, as it allows to easily check for the kind of error one should expect and recover an error from an approximate souvenir etc... however modularity asks that each module be able to introduce its new errors
• error may happen during dynamic initialization (unless you ban code from running then, not easy to check), to circumvent the lifetime issue, it is better to only rely on objects that will be initialized during static initialization (this is the case for string literals, for example)

In general, the simplest thing I have seen was to use some integral constant to identify an error and then have a table on the side in which you could retrieve other information (potentially a lot of it). For example, Clang uses this system for its diagnosis. You can avoid repeating yourself by using the preprocessor at your advantage.

Use such a header:

#define MYMODULE_ERROR_LIST     \
     ERROR(Code, "description") \
     ...

#define ERROR(Code, Desc) Code,

class enum ErrorCode: unsigned {
    MYMODULE_ERROR_List
    NumberOfElements
};

#undef ERROR

struct Error {
    ErrorCode code;
    char const* description;
};

Error const& error(ErrorCode ec);

And a simple source file to locate the array:

#define ERROR(Code, Desc) { Code, Desc },

Error const ErrorsArray[] = {
    MYMODULE_ERROR_LIST
    {ErrorCode::NumberOfElements, 0}
};

Error const& error(ErrorCode const ec) {
    assert(unsigned(ec) < unsigned(ErrorCode::NumberOfElements) &&
           "The error code must have been corrupted.");
    return ErrorsArray[ec];
} // error

Note: the price of defining the macro in the header is that the slightest change of wording in a description implies a recompilation of all the code depending on the enum. Personally, my stuff builds much faster than its tested, so I don't care much.

This is quite an efficient scheme. As it respects DRY (Don't Repeat Yourself) it also ensures that the code-description mapping is accurate. The ERROR macro can be tweaked to have more information than just a description too (category, etc...). As long as the Error type is_trivially_constructible, the array can be initialized statically which avoids lifetime issues.

Unfortunately though, the enum is not so good at modularity; and having each module sporting its own enum can soon get boring when it comes to dealing uniformly with the errors (the Error struct could use an unsigned code;).

More involved mechanisms are required if you wish to get beyond a central repository, but since it seemd to suit you I'll stop at mentioning this limitation.

Answer 3

I'd keep it simple, in a header:

enum ErrorCode { E_help, E_wtf, E_uhoh };
const char* errstr(ErrorCode);

Then in some .c or .cc file:

const char* error_strings[] = {
  "help!",
  "wtf?",
  "uh-oh"
};
const char* errstr(ErrorCode e) { return error_strings[e]; }

Answer 4

Not a lot of detail in your question, but with what you've posted I would consider a singleton class for handling your error messages. You could create methods for accessing messages by code number or enum. Then you can implement internationalization or whatever else you need for your specific application. Also, if you do decide to use SQLite or some other file-based solution in the future, the class interface can remain intact (or be extended) minimizing impact on the rest of your code.