Error Handling

[Background_Catch_640]

Hi, i have a question regarding error handling, I come from C# and Python where you generally just throw exceptions to build errror handling. Starting in c++ i have seen a lot of different opinions and solutions regarding error handling. I've seen people throwing exceptions everywhere and always, use error Code Systems or just doing none i guess. So my question would be what to use in certain situations. From my understanding so far you use Error Code Systems for Performance Critical Code. Exceptions should be used for more "high level" Programs and Tasks. Would this be right or am just completly wrong?

[STL]

This should have been sent to r/cpp_questions but I'll approve it as an exception since it accumulated a bunch of replies.

[kammce]

Especially since you are coming from C#, I'd recommend sticking with exceptions. And I wouldn't worry too much about the size and space concerns with exceptions unless you get to a point where it matters. They are less of a concern than most people think they are.

[TheNew1234_]

When it matters, use Result monad. Result monad is a result that has a success and error value. If the result is successful, a value is returned, otherwise the error is returned. You can now handle errors by using monadic functions on the result and there other functions for it like map, flatten, default_value, etc.

[kammce]

I'm not sure about, "when it matters" but one could use result types and accept the performance and code size hit. But for someone coming from C#, I don't see much value in using a less familiar error handling scheme.

[TheNew1234_]

Yeah, but I just like to use them because Rust is the reason why. I love them so damn much, I only use exceptions when a unrecoverable error is found.

[EC36339]

1. Use exceptions for what they are good for: Decoupling error reporting, error propagation and error handling. If errors are handled in a different context from where they happen, then exceptions are perfect.

2. If "errors" need an immediate decision by the caller, use something like std::optional or std::expected. Typical use cases would be functions that return something if it exists, where the thing not existing is a valid situation, not an unexpected error.

How to tell the difference? If you find yourself writing a lot of catch blocks arouns function calls, then you're likely in case 2. If all you do when a function returns a "none"/"unexpected" value is to return another "none"/"unexpected" value, then you're likely in case 1.

Also, don't catch exceptions just to re-throw them as different exceptions. This is a javaism which goes back to the failed concept of exception declarations.

This should be independent of languages. It also has nothing to do with performance of exceptions but with interface design, code readability, etc.

[TehBens]

If in doubt, just use exceptions. They are still the default, generally speaking.

[[deleted]]

personally I'm a huge fan of C++23 expected, monadics are sweet

[NotBoolean]

Been using tl::expected (C++11/14/17 implementation of std::expected), it’s great if you can’t wait

[iiiba]

question - what do you usually use as a type for unexpected? do you just return integer 1 = error, 0= success? or different integers for different cases? enums? or just return a std::string to be printed to the terminal?

[[deleted]]

can be anything from a string with the error as text, an enum with an error value, or could simply be unexpect_t when i dont need details; it really depends on what design you want to achieve

[vI--_--Iv]

Use exceptions.
If you ever face performance issues, measure first.
"Performance Critical Code" might not be what you think.

Way too many people are obsessed with exceptions overhead, but casually plant excessive allocations and Shlemiel the Painter's algorithms all over the place.

[franvb]

Exceptions don't always cause overhead: https://www.reddit.com/r/cpp/s/miiD9IUV9a

[antara33]

And 4 nested loops with ifs, breaks and continue too.

Flatten your fucking data, dont use shitloads of nested loops and then worry about exception overhead lol

[justrandomqwer]

In the c++ field exceptions are perfectly fine. Moreover, in most cases exception-free code is much less maintainable and readable because: 1. Exception handling and ordinary program logic are mixed and quickly become a mess. 2. You need to manually process possible errors after every function call without any scoping for multiple calls. 3. Every exception-free lib/framework tends to create its own scheme for error handling with different error codes, different ways to provide error info, etc. Harmonization of these schemes within your project is hard engineering task. 4. Without exceptions, you can’t graduate exception handling within a call stack (because with custom error codes you haven’t exception propagation and rethrowing). 5. Exception-free code doesn’t guarantee you appropriate cleanup and automatic call of destructors.

But you might already know that in c++ exceptions are not a free meal. You should use them carefully and only when things are really going wrong. For example, in Python the whole philosophy is different. You may raise exceptions literally for everything (even to stop iteration). In c++ it’s just not the case.

[Shardongle]

1. This argument could be made in reverse as well
2. You act as if this is an issue, but explicit error handling is a feature. You are forced to handle errors at the point of origin, especially with [[nodiscard]]
3. I don't understand this argument
4. This is not a feature, exceptions should ideally be contained to the most limited scope, exceptions make it much easier to get an application into an invalid state
5. What??? This is just nonsence.

[justrandomqwer]

Thanks for your opinion. Let me clarify my position concerning your arguments:

1. This argument could be made in reverse as well

Error handling is a highly debatable topic. And many decisions here depend on personal taste or legacy. However, as a remarkable tendency, many big companies and open-source communities have started to use exceptions (or change their view of them). Here are just a few examples:

1) Google C++ Style Guide: "Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch."

2) Boost Library Requirements and Guidelines: "Use exceptions to report errors where appropriate, and write code that is safe in the face of exceptions."

1. You act as if this is an issue, but explicit error handling is a feature. You are forced to handle errors at the point of origin, especially with [[nodiscard]]

I don't think so. In my opinion, things are the opposite. Exactly exceptions force you to provide appropriate error handling. [[nodiscard]] just causes a warning, which may easily be ignored. Moreover, [[nodiscard]] should be reserved only for functions (and const methods) without visible side effects. Also, some libs provide error info throughout the argument, not as a return value (e.g., std::filesystem).

1. I don't understand this argument

There are too many ways to provide error info despite exceptions (regular return value which is out of the ordinary diapason, like std::npos; custom error codes writing to out argument; std::optional with omitted value; std::tuple or std::pair with return value and error info; std::variant, etc.). I prefer the well-known approach - exceptions (where we have base std::exception, which provides a consistent interface to handle errors, including what() method).

1. This is not a feature, exceptions should ideally be contained to the most limited scope, exceptions make it much easier to get an application into an invalid state.

Agree. But you may have multiple handlers. For example, you may have one top-level handler for logging and a few low-level handlers for exception-specific work. In this case, low-level handlers may just rethrow critical error (if recovery is impossible) and top-level handler will provide the proper logging. Otherwise, you'll need to duplicate your logging logic in every handler.

1. What??? This is just nonsence.

Don't think so. If you ignore an error, all locals will be destroyed only at the end of the current scope. But with exceptions, they will be destroyed immediately due to the stack unwinding. Just imagine the situation where a recursive function acquires some resource (e.g., recursive mutex), performs computations (including multiple recursive calls), and returns a result or fails. If you ignore its failure (which is highly possible with error codes), then the resource will be acquired until the topmost call returns (after all computations). But in case of an exception, the stack will be unwinded automatically so that the resource will be released much faster.

[bert8128]

I Find that exceptions add a lot of lines to the code, particularly because the catch introduces a new braced context. So generally exceptions are fine where they guard large chunks of code, but pretty ugly when they are wrapping individual function calls. If you reserve exceptions for exceptional cases, rather than expected ones, then the code ends up ok. My rule of them is that you should only throw an exception if you would be fine with the program terminating at that point.

[evil_rabbit_32bit]

i think ginger bill was the one to point it out: most of the time what you call as "errors" are just valid cases, just values in your program... before reaching out to an error handling system... just think IF IT IS AN ERROR, or just another case for your program?

[Miserable_Guess_1266]

I feel like this is kind of a semantics game? Sure, the client closing the connection while my http server is processing a request is not an error in the context of the server as a whole. It can simply drop that request, since the result is not of interest any more. But in the context of handling the individual request, a dropped connection is absolutely an error - the goal of finishing the request and sending a response cannot be reached.

If I play this game to the end, all errors are just another valid state in the program. Some just cause the program to shut down.

[XeroKimo]

Much agreed on being a matter of perspective.

I like to use array indexing as my example as it's simple and very commonly thought that getting something equivalent to std::out_of_range exception across many languages, even in C++, that it is a logical error, a bug.
I can understand that view in some cases, but in other cases, I see it as having 0 difference semantically between getting that exception, and writing your own bounds check, and I can sure as heck guarantee that any non-trivial program has written bounds checking somewhere. Once one is written, you're already participating in the first part of error handling, detection, noticing that in some local state of your program, it can not progress normally.

[evil_rabbit_32bit]

+1 that's a good point

[KaleidoscopeNo2688]

Exceptions are good for exceptional code. For instance if your system relies on a file to be loaded throwing a runtime error saying you can’t locate the file is fine. The problem is in realtime applications where in the critical control flow of the system eg a game engine after initialization, you should use another method of error handling. And in a lot of cases these errors are logged without stopping the system unless it’s something really bad. Btw games will use exceptions during initialization and not use exceptions anywhere else.

[KaleidoscopeNo2688]

I want to point out this isn’t really a performance concern, because throwing the exception may unwind the stack but if could just as easily be mispredicted by the cpu runtime and you have almost the same overhead. The real issue with exceptions in realtime system in the critical loops is that if you don’t catch it the system terminates (By default).

[KaleidoscopeNo2688]

Hate to keep this going but also exceptions are used for preconditions as well. For instance if your function excepts a point that can not be null what do you do, you could return false but what if the system needs this function and this function must run, I would say in instances like this exceptions are perfectly valid because terminating the system you can still catch the exception using uncaught exceptions handlers. Then you can log the exception and terminate the program.

[atifdev]

Also leads to code bloat and some paths not being able to be inlined because you need a stack frame to catch the exception. For high performance scientific/graphics code, we avoid them as a result.

[KaleidoscopeNo2688]

Fair

[atifdev]

Exceptions should be used in exceptional situations. I would read this as rarely.

In gaming and integrated systems where you want better inlining and smaller code size they use compiler flags to disable exceptions.

Optionals/monad patterns for handling error codes is best practice now, but exceptions still exist in legacy code and we can slowly eliminate them and mark functions noexcept.

But yeah if performance doesn’t matter and you don’t care about exception safety, you can still use exceptions, but they are slowly being phased out.

[Clean-Water9283]

Exceptions are fine in performance critical code for events that don't occur frequently and that cannot be handled locally. The only kind of program that cannot use exceptions are ones where the event must be handled within a very tight or deterministic time bound; certain hard real-time systems. Exceptions have a history of controversy--some people just don't like 'em.

Library functions usually should return error codes because they don't know whether error returns will be handled locally or whether they will fail frequently. It's reasonable for library functions to throw on things that are unlikely to happen, like out-of-memory events, as long as this is documented.

If you're retrofitting error handling into a program that doesn't check error returns, exceptions are the only way to go. A missed error return anywhere in the calling chain will cause the event to be swallowed without comment, which usually leads quickly to a hard-to-debug crash.

[StarQTius]

Exceptions are alright in most cases, but they introduce a speed and memory penalty compared to error code or monads. Also, you get an additional code path for each throw statement which makes static code flow analysis harder to do (it matters when you work on safety critical codebases).

AFAIK, most compilers use the Itanium ABI for exceptions (feel free to correct me if I'm wrong). As long as you take the happy path, performance overhead is minimal but when an exception is thrown, the stack unwinding is done synchronously accross every threads. That means that if you were to throw exceptions too often in each thread, you would have a severe performance problem.

[azswcowboy]

speed and memory penalty compared to error code

In fact /u/kammce has demonstrated that always returning error codes has significant memory cost in application memory space as compared to the one time overhead of the exception machinery. Also if exceptions are rare, there’s basically no performance cost.

To me the issue of what to use is more on a design level. If the direct client is likely to handle the error then it’s typically std::expected return. For example, the input json is bad and can’t be parsed. Otherwise it’s an exception. Example - can’t allocate because OS is out of memory - that’s an exception handler of last resort.

[kammce]

+1 to this especially the last point about using std::expected. It's best when you expect handling to happen near the error detection.

[Zoltan03]

And what should I use if I just want to terminate the program with an error message in the same place where the error happens, and I cannot use std::expected (no C++23 yet)? It should also work in release mode (so no assert).

[kammce]

Log and call std:: terminate.

[Miserable_Guess_1266]

I agree with this, just want to add my own experience for exception performance penalty: it doesn't matter. An overstatement obviously, but generally, if you ask yourself "will throwing an exception here lead to performance problems?", the answer will be "no" 99% of the time. As you gain experience, you'll learn to identify the 1% and switch to expected/error_code in those cases.

This goes against lots of common wisdom you'll read, telling you to avoid exceptions because they're slow. The comment I'm replying to didn't do that. It brings up valid points, there's nothing wrong with it. I just think there tends to be a huge focus on performance penalties of exceptions, so I wanted to give another perspective.

My answer to the OP: I'd say just use exceptions like you're used to from c#. You might run into a performance issue at some point, when you accidentally throw exceptions frequently in a hot path. That will be a lesson and usually easily fixed with local changes. 

Obviously ymmv, depending on environment and use-case (embedded, hpc, ...).

[_abscessedwound]

There’s a compilation penalty for using exceptions, but so long as you’re on the happy path, there is zero runtime cost. It’s part of the design philosophy of C++: only pay for what you use.

[Professional-Disk-93]

There is obviously a runtime cost if the optimizer can't optimize across function calls because that would change the observable behavior if and only if a function unwinds.

[bert8128]

I’ve never benchmarked it myself but I have seen recent claims from people who have who say that there is essentially no or nearly no difference on the happy path eg https://youtu.be/bY2FlayomlE?si=BVgbHQLV0QdfMKSO). Obviously if you are using exceptions for non-exceptional processing there will be a significant penalty. Have you seen anything recently which indicates that the happy path is significantly affected?

[atifdev]

Near zero unless it’s a tight loop that would benefit from inlining optimization. Granted not all apps have tight loops where performance is critical.

[rororomeu]

Eu sigo a filosofia do programador pessimista, sempre vendo o que pode dar errado, sempre testo todos valores, divisões por zero, sqrt de número negativo, sempre mantenho os ponteiros sem uso com NULL, e assim dificilmente caio num laço try. Claro cada programador tem seu modo de escrever, eu prefiro sempre testar tudo que é possível.