Question

In my last two projects I’ve seen the strange guideline, “All Methods/Functions should return error-code using some common ERROR_CODE type”. In both projects ERROR_CODE is an int typedef.

Is there any good reason doing it in C++? Some MISRA requirement or something like that?

I can see only disadvantages:

• If a function should return a value, it is done by argument reference. e.g.:

  string s;
  ERROR_CODE err = getString(s);

• The importance of a function is not obvious. All looks the same. The list of errors conntains hundreds of errors from low level errors to some domain specific errors.

Have you experienced this programming style? Are there good arguments against it or for it?

Answer 1

I think it’s a very bad style for several reasons.

1. Like you’ve said, it forces you to pass pointers/references to store the actual result of a function.
2. Like you’ve said, the unified error code is ugly because it’s trying to unify all sorts of errors from all sorts of domains.
3. It creates an artificial dependency of all the program’s modules on the error code system, making it awkward to reuse a single module or small subset of modules in other programs.
4. Further, since some of the error codes are domain-specific, it’s actually introducing dependencies between unrelated object types/modules, since they’re all dependent upon a component that’s dependent upon the union of all of their possible error types.

My view is that any function/method which has more than a small manageable number of ways it can fail is either overly complex or poorly factored, probably both.

If you really want to return error codes, I would swap things around and pass the pointer to the error code as an argument to the function, and make the actual result the return value. Then I would choose one of these two approaches for implementing the error codes:

1. The simple way: throw away all abstraction of the error code and simply use int with a few universal error classes.
2. The heavy object oriented way: Provide a pointer to an internal “error object” where the base class is very abstract and can be shared between all components without introducing any dependency, and where each component defines its own component-specific error objects if needed.

A better approach if you’re using C++ would probably be using exceptions…