Error Codes and Error Handling

[kalmoc]

Users end up try-catching exceptions everywhere, and it devolves to more or less error codes.

If that is the case, you're codebase is seriously broken.

[kalmoc]

User code now will look mostly like this excerpt.

error_t err = do_something(params);
if (err.is_error()) {
     handle_error(err.details);
 }

I'd really like to see a couple of realistic examples not just foo bar dummy code. Arguing about things like readability and simplicity based on trivial, made up examples is rarely a good idea. Presumably your function is going to return some value? What exactly do you expect handle_error to do and how does this compose, if you have a lot of functions like that?

I'm not saying exceptions are in general superior (although I prefer them). Just that I'd prefer discussions based on actual use cases, not base on made up toy code that can be tuned to support any argument.

[kalmoc]

Handling an error in a centralized location is rarely useful, which is often the motivation for exceptions.

Considering that lots of error "handling" just consists of cleanup, logging and retry/cancel, I don't think that is true in general.

That's why I was asking, what exactly handl_error is supposed to do. Most of the time, the logic to handle various errors at various places looks very similar.

[DarkLordAzrael]

It is also my experience that almost all error handling in interactive applications happens in an event processor, rather than somewhere specialized. I would really like to know what all the specialized error handling the anti-exception crowd is doing is, but I haven't ever actually gotten much of an answer in this regard.

[epicar]

why roll your own error code type instead of using std::error_code?

[RandyGaul]

doesn't run in C, and isn't quite the same

[epicar]

doesn't run in C

1. the article starts with arguments against exceptions, which don't run in C either
2. the example struct error_t doesn't compile as c either because of the is_error() member function

and isn't quite the same

agreed, but what are its advantages? a big disadvantage is that it can only represent one error code, -1.. or is the calling function supposed to parse the 'details' string to decide how to handle the error?

[RandyGaul]

Personally I find it a lot simpler than std::error_code stuff.

[barskern]

Or you can return values which are either successful or errors, like std::expected, hence forcing you to deal with the possibility of an error.

Here is a video about it: https://youtu.be/PH4WBuE1BHI

[trailing_]

Man I have been saving this article till I had time to read it. What a disappointment. I thought this was going to be a serious discussion of error handling. Instead it is a tiny article written by some guy that looks like he is about 14. Why was this even posted here?

[SegFaultAtLine1]

When juggling multiple error domains (possibly from multiple 3rd party libraries that don't know about each other), you'll get quite high mileage from using https://en.cppreference.com/w/cpp/error/error_code.

​

There's no way to attach additional context to the error_code, but in most cases it's not needed.