that's just false. Exceptions were not a mistake and std::optional isn't even a good type to replace more than communicating that there is no value. It's as g

that's just false. Exceptions were not a mistake and std::optional isn't even a good type to replace more than communicating that there is no value. It's as good as returning nullptr, in this case. And what strength of an exception guarantee does one really need? A basic guarantee is not that bad to give and most things do not need to worry if they don't use unmanaged resources without RAII types(e.g pointers). But the big thing is, a large amount of code does not have error states at all, they always work. Another chunk have preconditions, that are generally developer errors, that shouldn't be throwing either. That leaves the parts that interact externally. And here is where one learns, it's not a dichotomy of exceptions or error flags/results... it can be both. It's more to do with the shape of the code. One example is, one is passing a string buffer to a parser, an exception is probably fine as the error cannot be dealt with within the parser. It didn't create the malformed document and cannot fix it. To use error types will greatly complicate the inner workings of the library as it has to deal with errors at a majority of calls internally. This leads to more bugs(assuming more code == more bugs) and complexity/branches. One already paid for the branch to check for the error in the document too, now they have to pay for branching up the stack. Exceptions strong part is that they cannot be implicitly ignored. One can do that with error types that force a read prior to destruction too though. For short distance things, where one is handling the error state after the call, not throwing is fine.