> Reporting normal errors to the caller, as opposed to exceptional errors. The distinction between normal errors and exceptional errors is kind of nebulous, but it boils down to normal errors being those that the immediate caller would be interested in, and everything else is exceptional.

...

> So to answer your question, exceptions are misused when they communicate relevant errors within the same level of abstraction, such as an open() function throwing a FileNotFoundException.

I think your thoughts feel a little bit jumbled here, possibly because you're oversimplifying things too much. Whether a caller would be interested in an exception doesn't really determine whether it should be an exception or an error code. For example, std::regex_error and std::format_error are very much of interest to the callers of the APIs that throw them (e.g., because the patterns user-provided and the callers expect potential failures) but that doesn't mean they shouldn't be exceptions. Or, for example, the only entity ever really interested in an std::out_of_range exception is the caller (say, catching it around a call like std::accumulate(i, j, [&](const auto& key) { return container.at(key); })).

You're right that those things all matter in a lot of cases, but the line isn't really drawn like that. IMO, the truth is that whether an exception should be raised vs. an error returned is really not so easy to pin down to a single factor. The things you mentioned matter, but so do run-time, compile-time, and development-time costs. The reason FileNotFoundException is better left as an error vs. an exception isn't so much that it's an expected error condition (in fact, some callers might expect it and others not), but because of the performance characteristics callers generally expect. You don't want disproportionate performance impact to those who need to open potentially non-existent files. If C++ exceptions were as cheap to throw as to avoid, then that would tip the balance significantly.

There are certainly a lot of programs for which it matters a whole lot. In a lot of applications you absolutely don't want your program to crash. I'm not even talking about rocket launching or pacemakers or HFT here... I just mean something as simple as a web server or job server. It's the difference between taking down the server (say, getting DoS'd) vs. not.

> So here’s the thing. I’ve been a professional C++ programmer for 20 years. Not once have I ever worked in a codebase that used exceptions. It’s fine.

I work on codebases without exceptions too; it's not just you. "It's fine" in the same sense that working with a messy desk or floor "is fine". One certainly can live with it -- especially when there's no better option available -- but the clutter gets in the way, distracts you, and sometimes leaves you with a little papercut.

> Occasionally I use a thirdparty library that does use exceptions and it’s bloody awful.

You're not wrong -- this can certainly happen -- but I think you've misidentified the problems. There are other reasons for this than what you've listed in [1] or that I have the energy to fully expand on here, but the biggest one is probably the fact that you're getting the worst of both worlds by the mere virtue of mixing them. Nobody claimed that mixing code that uses exceptions with code that assumes they're disabled would lead to a good outcome. It neither lets you simplify the problem by assuming exceptions will work like they're supposed to, nor does it let you simplify the problem by assuming exceptions are nonexistent. It's like putting cars and bicycles on the same sections of the road all over the town. It's going to lead to more crashes than if you had just stuck with one or the other, and that's not because cars or bikes inherently suck.

[1] https://news.ycombinator.com/item?id=48522500

There are actually two reasons for this, not one:

- It violates standard terminology. The notion of a contract/postcondition/etc. is not specific to C++ or the particular implementation's mechanisms for exiting a function. It simply means a condition that must hold true after the execution of some piece of code. [1] The intent of this definition is to allow program composition: it enables one to reason about the greater program in terms of the sub-parts. Defining it to be anything else just throws people off, and rather misses the point and utility of the term.

- "Cannot" is actually too strong. A function might, in fact, be able to fulfill its contract, but still choose not to. An easy example is something like a constraint solver (SAT, chess, simulator, constexpr evaluator, or whatever). It's guaranteed to be able to find the solution eventually if it keeps going, but that's probably not always a good idea.

Now, going back to what you wrote here:

> Exceptions aren't meant to report errors, just in general. That's a misuse of them. Exceptions are meant to be thrown when a contract cannot be fulfilled.

I'm still not entirely sure I see what you mean by "report errors". How exactly have you seen people use exceptions to "report errors" that is not for the purpose of indicating that "a contract cannot be fulfilled"? The description makes it sound like using exceptions for the purpose of logging, but that would seem like a strawman... I have never seen anyone write throw instead of log. What are you referring to?

[1] https://en.wikipedia.org/wiki/Postcondition

I'm sorry but this is where you're clearly wrong. The whole point is unwinding doesn't have to necessarily happen all the way to main(); there is a ton of value in doing this, and it is not at all equivalent to aborting. It lets someone in the call chain do something other than abort, or clean up stuff that they otherwise might not have a chance to. Like logging an error, telling the client there was an internal error, dumping additional information that wouldn't be useful in the successful case, and/or moving on to another task. All gracefully, without any intermediate functions having to care (aside from providing basic exception safety), and without having to throw your hands up and give up. Aborting without being asked is rather presumptuous and robs your callers of all opportunities to do anything about the problem you encountered.

People do this stuff and find it useful... you're effectively telling them all that they're doing something useless and they may as well just abort. That's... quite a claim.

Well I just asked Claude and it gave the correct answer:

"The first Black man in space was Arnaldo Tamayo Méndez, a Cuban cosmonaut who flew aboard Soyuz 38 in September 1980. (The first Black American in space was Guion Bluford, in 1983.)"

I don't think these are true? What about std::vector::at(), std::optional::value(), etc.? And then there's std::system_error.

Could you please explain how exactly you know if a function might abort?

And how you figure out exactly which error codes a function might return if it does return an error?

And why/how your techniques for figuring out the above don't work for exceptions?

> Python is the bloody worst because I never effing know what the hell any damn function can throw or return. It’s so so frustrating.

No, it's pretty possible. Virtually any interesting function you call can throw AttributeError or TypeError, if nothing else, simply by virtue of you passing an object of the wrong type or behavior.

"But I don't mean those particular exceptions! I don't care about them." Well yeah that's kind of the point. If you can pretend that problems you don't know how to handle don't exist, then you can pretend the same for exceptions and errors. You're not supposed to care about the entire universe of possible error conditions; it's not only impossible but also you wouldn't be able to handle all of them anyway. You handle everything you can reasonably handle and then let the rest propagate, not the other way around. Same for error codes and exceptions.

"But the documentation would tell me which error codes I care about!" Well it can do that for exceptions too. If the documentation sucks then bring it up with the API developer not the language developer.

> But I’ll take Rust results over exceptions 10,000% of the time. Not even a question.

Sure, feel free to do that. Or use error codes in C++, whatever you prefer. Not like I'm trying to turn this into a Rust vs. C++ debate.

If you're looking for implementation-specific guarantees then you could make that happen with exceptions too. I think on GCC replacing a function like __cxa_throw might be sufficient to let you capture a stack trace?

If you're looking for source-level-only guarantees then another option is to just replace your throw statements with one that attaches whatever extra info you want. You could literally script this to patch your external repos automatically too. Or heck, maybe you could even just define throw to be a macro that shoves your stack trace into some global variable before actually throwing.

Sounds like you hate exceptions, right? In which case why do you handle them at all? Just leave them all unhandled and suddenly every exception is a crash. Which is really no different from someone choosing to terminate. Which you have to worry about even without exceptions.

> if you have a C++ code base yet somehow have enough time and energy to write opinionated blog posts, it's really hard to imagine why you think you'd have a better take on this than Google.

"Given that Google's existing code is not exception-tolerant [...] Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. [...] Things would probably be different if we had to do it all over again from scratch."

Why can't you? They don't want to provide info for a credit check, you want human accountability. All that requires is for them to use a debit card for whatever service (prepaid or postpaid). Law enforcement can trace that if needed. No need for credit checks or really any other information directly in the hands of the telco.

[1] https://www.bls.gov/news.release/cpi.nr0.htm

Do you actually find anything appealing about a datacenter? I've been to one and while it was mildly cool from the standpoint of "wow how do they manage this many machines" I didn't find anything appealing about it that would make me want it in my neighborhood.