Error handling and polymorphism

Question

I have an application with some bunch of code like this:

errCode = callMainSystem();
switch (errCode){
    case FailErr: error("Err corresponding to val1\n");
    case IgnoreErr: error("Err corresponding to val2\n");
    ...
    ...
    default: error("Unknown error\n");
}

The values are enum constants. Will it make some sense to have something like:

// Error* callMainSystem() 
... Some code
return FaileErr(); // or some other error

// handling code
Error* err = callMainSystem();
err->toString();   

The Error class may be made singleton as it only has to print error messages.

What are the pros and cons of above methods,size is an important criteria as the application needs to be supported on embedded devices as well.

P.S: I don't want to use exception handling because of portability issues and associated overheads.

Answer 1

IMHO polymorphism would be overkill here, as you don't actually need different behaviour, only use different data per error code. I would use a simple map<ErrorCode, string> instead to store the mappings from error codes to messages.

The polymorphic solution would require the extra overhead of creation and destruction of Error instances. I can't see how to make Error a singleton; however, you could implement it as a sort of typesafe enum like in Java (i.e. a fixed number of constant instances). However, hardwiring their behaviour (e.g. printing error messages to stderr) can make it awkward to unit test your code.

Answer 2

When you say:

I don't want to use exception handling because of portability issues and associated overheads.

There really aren't any, assuming an even moderately up-to-date compiler. All you are doing is reproducing in your code what the C++ compiler will do for you anyway.