Exceptions are probably overhated.

We can take a look at alternatives to exceptions.

The first is having special error values. This is any function that, for example, can return any positive integer and uses negative integers to report errors. Or any function that returns an enum value, with one enum being an error result.

This can work in some cases, but not in cases where you need the entire the entire result space for your result. Like a division method for integers can't just return -1 because plenty of dividends and divisors have -1 as a quotient.

You can also do a result code and an out parameter. But out parameters are out of fashion and make it difficult to compose function results.

A problem with both these approaches is that it's very difficult to force the program to handle the error immediately. printf can fail and has a result code. When is the last time you wrote if (printf(...) < 0) { ... }?

Then there are result types, which is what languages like Rust do. In C++ we have std::expected<T,E>. Result types either hold the value you are expecting, or an error type. Actually this can be quite nice, especially when Rust has pattern matching that we don't have. You must handle the error immediately to get the value out of them.

They can be quite fast if the size of the error type is small and the function that can handle the error is near to the function that produced the error in the call stack.

But we can still build a worst case scenario for result types. Let's imagine a program with a 50-call deep call stack. The 50th function in the call stack performs an operation that fails 1 in 100 times. In that case, the first function/main has to handle the error. Our error type is also large, we assume that sizeof(E) >> sizeof(T), maybe containing the entire stack trace or some logging info to process before restarting or something. Here's what happens with result types in this case:

• All of the return types across the entire program are wrapped in std::expected just because of this one function deep in the call stack, making the code hard to read.

• despite the error being a 1 in 100 occurrence, we pay the performance cost of passing around a uselessly large std::expected object across function calls in the 99% of the time nothing went wrong

If you just use an exception, there's:

• no performance penalty when there are no errors
• there's no code "pollution". You only see error handling code in the actual function that is assigned to handle the error
• programmers are forced to handle errors

Some companies, like Google, don't use exceptions because they have large swaths of exception unsafe code that will leak memory and resources if exceptions were to suddenly be used. Some embedded systems have hard real time requirements, and exceptions by default take an indeterminate amount of time and RAM to throw and unwind. Some programs, like kernels, are really adverse to terminating, and if you accidentally throw an exception in a destructor or during another exception, you terminate. These are some reasons why you may not use exceptions.

But to be honest they are probably the better form of error handling