views:

144

answers:

3

I am currently involved in developing a low level network application. We have lately run into the issue of error reporting concerning both user land and debug land. Given that some errors might fire up from lower level functions, libraries ... reporting the exact error status (code, messages, env...) from one layer to another higher layer has revealed to be somewhat cumbersome.

However we have thought to switch back to using exceptions but recently a pal has came out with this approach : Using a class Error_Buf which holds sufficient informations about what causes the error as such error code, buffer message, and passing it as a parameter in functions. Hence whenever something goes wrong, an adequate message and error code are set in error->buffer and error->error_code for example and then are forwarded back to the calling function and an adequate return value is sent.

This is actually what we use to do in c (at least libnet does something similar) but how is this near or far from efficiency and robustness, code maintainability might be an issue too.

Thank you,

+8  A: 

The advantage of exceptions is that callers cannot ignore them. OTOH, I've seen so much code that ignores return values.

Also, in some code, if you check all calls for possible errors, the algorithm will be buried under error handling code. With exceptions, that's not an issue.

sbi
it depends, some languages allow to completely ignore exceptions (vb.net), ore ignore some of them (runtime exceptions in Java). also a lazy programmer can always do nothing in the catch block (and they do!)
vulkanino
In these cases the exceptions might be ignored by the programmer but not by the runtime, thus the program will not end up in a state ignoring an error. With no exceptions a problem can be ignored and then code make use of an undefined state
Mark
@Mark: vulkanino's point was that a programmer could chose to ignore an exception by catching it and doing nothing. Of course, at least they are explicitly ignoring it instead of implicitly ignoring it.
Niki Yoshiuchi
@Niki: The difference is that with exceptions they _deliberately_ need to do this. (It's the old difference between stumbling over Murphy or Machiavelli that is stressed so often for C++.)
sbi
+2  A: 

Exceptions handling is much better, it allows to keep code clean and short, without testing every function for success/failure and return on failure. It has runtime cost, if you want something super-fast, think about C-style error handling.

It is possible to use combined approach, when some low-level time-critical functions use return values, and all other code uses exceptions.

Alex Farber
It has been mentioned timed and again on SO that exception handling has basically zero cost (when no exceptions happen). So spped should not be an issue. Also the cost of exception handling when exceptions happens is comparable to the cost of adding all the tests for error codes that would be the alternative. So if exceptions happen in exceptional situations (ie not often) then exceptions is always a winner in terms of speed.
Martin York
There IS exception handling cost. In most situations it can be ignored. I use exceptions in 99% of my code. Bur every real-time programmer has situations when it is necessary to count every ms. In this case "basically zero" is not zero.
Alex Farber
A: 

I prefer error codes, this is because, as a programmer, you are forced to think of errors at every level of code and handle them appropriately. This might a simple error occurred here trace entry.

With exceptions, by the time one catches them one is often quite far removed from the source of the problem. If the problem results from a genuine bug, one is often too far removed to track it down effectively.

doron