3

What error handling schemes people use in c++ when its necessary, for X or Y reason, to avoid exceptions? I've implemented my own strategy, but i want to know what other people have come up with, and bring discussion on the topic about benefits and drawbacks of each approach

Now, to explain the scheme i'm using on a particular project, it can be summed up like this. Methods that would normally require to throw, implement an interface like:

bool methodName( ...parameters.... , ErrorStack& errStack)
{
   if (someError) { errStack.frames.push_back( ErrorFrame( ErrorType , ErrorSource ) );
   return false;
   }
   ... normal processing ...
   return true;
}

in short, the return parameter says if the processing was ok or an error occurred. the Error Stack is basically a std::vector of error frames that contain detailed information about the error:

enum ErrorCondition {
            OK,
            StackOverflowInminent,
            IndexOutOfBounds,
            OutOfMemory
        };


        struct ErrorFrame {
            ErrorCondition condition;
            std::string source;

            ErrorFrame( ErrorCondition cnd , const char* src ) : condition(cnd) , source(src) {}

            inline bool isOK() const {
                return OK == condition;
            }
        };

        struct ErrorStack {
            std::vector< ErrorFrame > frames;

            void clear() {
                frames.clear();
            }
        };

The advantage of this approach is a detailed stack of errors similar to what java exceptions give, but without the runtime overhead of exceptions. The main drawback is that (besides the non-standardness and that i still have to handle exceptions from third-party code somehow and tranlate to an ErrorCondition), is that is hard to mantain the ErrorCondition enum, since multiple components of the source base require different errors, so a second version of this strategy could use a inheritance hierarchy of some sort for the errorConditions, but i'm still not confident about the best way to achieve it

lurscher
  • 25,930
  • 29
  • 122
  • 185
  • 9
    "The advantage of this approach is a detailed stack of errors similar to what java exceptions give, but without the runtime overhead of exceptions." You do realize that the "runtime overhead" of using exceptions is insignificant compared to the cost of maintaining this stack, right? – James McNellis Nov 11 '10 at 04:09
  • maybe i'm missing your point, but my understanding is that exception handling has runtime-costs even when no exception is being thrown. In this case the only additional cost when there is no error is passing an additional reference on each relevant function – lurscher Nov 11 '10 at 04:12
  • 1
    there is a bunch of overhead in your implementation as each function has to be checked to see if it passes or fails. – Keith Nicholas Nov 11 '10 at 04:24
  • 3
    Since you are using the standard library `string` and `vector`, you are already using exceptions, since the standard library allocator has to use exceptions to communicate allocation errors. – James McNellis Nov 11 '10 at 04:26
  • 1
    The vast majority of exception handling overhead is incurred only when an exception is thrown. During normal operation, the overhead is less than what you're doing here. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" -- Knuth – Mud Nov 11 '10 at 04:28
  • James, he wouldn't incur string or vector overheads unless there was an error..... but he would have to check every function to see if it passes or not every single time – Keith Nicholas Nov 11 '10 at 04:33
  • eg, if he had a function a that called function b c d b c and d have to be checked and return from function a if they had an error. if any of those functions are in a loop, it just gets worse and worse. a try catch around "a" would have a tiny overhead, but then nothing. – Keith Nicholas Nov 11 '10 at 04:35
  • @Keith: I don't disagree with your assessment. In my first comment, I was lumping everything into "maintaining this stack," since testing the return values of the callees is required to maintain the stack. My comment about `string` and `vector` was merely that if exceptions are not being used (for whatever reason), then you can't use those classes (perhaps that was confusing?) – James McNellis Nov 11 '10 at 04:37
  • I see: excellent points, specially the fact that im checking in each function. I based this approach in the c-approach to error handling (this for example: http://stackoverflow.com/questions/385975/error-handling-in-c-code). I think this (checking return values for error codes) overhead is impossible to avoid in C error handling? – lurscher Nov 11 '10 at 17:27
  • depends if you want to use a "goto" or not :) – Keith Nicholas Nov 11 '10 at 22:12
  • a "goto" (or more precisely a safe longjmp, if that is what you meant) is not out of the question. I'm even considering boost::context library, still on the boost review vault – lurscher Nov 12 '10 at 17:50
  • There are architectures where exceptions are simply not available (think of embedded systems and "special" processors), so trying to devise an appropriate error-handling system is not a bad idea, even if it would be less efficient compared to exceptions, if these were available. You can avoid STL's exceptions by simply linking exceptions yourself with simple pointers. – Raúl Salinas-Monteagudo Oct 23 '14 at 08:31

1 Answers1

3

check out http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf Page 32 onwards

Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156
  • That discusses exception handling rather than alternative error handling strategies (although it does list the alternatives briefly). – einpoklum Apr 29 '15 at 06:30