[grandinj]

On the other hand

() they solve a handful of use-cases really really well.

() if you are writing relatively decent C++, most code is pretty much exception safe already

() lots of abstractions are dangerous when mis-used

() they are sufficiently low cost that they almost never show up in the fairly extensive perf profiling I do on a large real-world application (LibreOffice). And LibreOffice throws exceptions __a lot__

(*) Except for toolchain writers, nobody cares how they are implemented

[tialaramex]

> LibreOffice throws exceptions __a lot__

They're terrible for this. C++ Exceptions are a perfectly good exception mechanism, but what C++ programmers are trained to do with them isn't exceptions but error handling and they're not suitable for that.

"I tried to create the file but it already existed" is an error - and now you're going to write the unhappy path code, this is the wrong place to have exceptions.

"I tried to create the file but the OS now says the abstract concept of files is alien to it" is an exception. You are not prepared for this eventuality, the best you can do is explain to the user as best possible what happened and hope a human knows what to do.

[TeMPOraL]

> error handling and [exceptions are] not suitable for that

I disagree :).

Exceptions are fundamentally equivalent to "return sum type" error handling pattern. In an exception-enabled environment, you can imagine every function returning some Foo is really returning a {Foo, Error}. Then, every call like below, outside of try/catch block:

  value = SomeFunction();

is secretly translated to:

  maybeValue = SomeFunction();
  if(!maybeValue) { return maybeValue.error(); }

You can devise analogous translations for code in try/catch blocks.

The fundamental difference between exceptions and an Expected/Maybe mechanism is that exceptions don't force you to be explicit about all those Maybe values. If you want to handle some Error three layers up in the call stack, you don't have to litter the intermediary layers with explicit Maybes everywhere.

(This is, unfortunately, also their drawback in typical implementations - the set of possible Error types in the hidden Maybes becomes effectively open-ended, when with explicit Maybes, it's constrained and visible in source code - and, perhaps more importantly, in the ABI.)

The other day I did an experiment - I wrote two equivalent pieces of nontrivial production code, one using C++ exceptions, and other using the tl::expected library. If you looked past the syntactic noise, they mapped almost 1:1 in terms of error handling and error recovery patterns.

[tialaramex]

Obviously we can translate one Turing complete paradigm into another, but that's not very interesting.

I argue that as so very often C++ the defaults are wrong. You can easily do the wrong thing, or you can go to a lot of effort to do the right thing, and since the right thing was technically possible C++ practitioners proudly declare C++ got this correct, and I say it did not.

[See also: everything about const from West Const being endorsed in NL26 despite being silly, through to the fact that the default is mutable for no good reason; the fact char isn't necessarily signed or unsigned you need to pick one if you care; need to explicitly use a provided replacement for the array type because the default built-in array type is broken; the default meaning of the literal "Hello, world" is this awful NUL-terminated byte array using that broken default array type; Way too many dubious implicit coercions, including narrowing conversions everywhere; I could go on]

Because we're not handling truly exceptional cases we will often want to treat the OK and error cases similarly. We tried to go outside and it was raining so maybe we should get an umbrella before venturing out again, but it wasn't on fire out there so we don't need to freak out and abandon our remaining plans to flee the fire immediately.

Exceptions make this needlessly difficult whereas sum types don't. The exception deliberately changes program execution, that is in fact its purpose, whereas the sum type lets you carry around the error and its context just as you would an "OK" result, until you need it for something or you decide you didn't need it and drop it on the floor.

Bad defaults get replicated for consistency. There are a lot of bad practices -- things you definitely shouldn't do -- that are now enshrined permanently in the ABI of the C++ standard library and so for consistency you're going to inherit those practices.

As a result I agree that Expected doesn't feel nicer in C++ today than exceptions but I argue that's a language defect, in a better language you'd find Expected worked better for the unhappy paths of your program and exceptions remained available for those truly exceptional cases that the programmer did not anticipate happening. Now, one programmer might feel that even "File already exists" truly is exceptional for their scenario, while another considers "Disk I/O error" to be merely an error they can cope with and no big deal (maybe the second programmer is writing an IT forensics program). That's going to vary, but the way for a standard library to reflect that is to use Expected almost everywhere and allow the developer who thinks "File already exists" is exceptional to throw for it, not have the standard library throw everything and then you race around trying to catch what you need to and hope you didn't miss anything.

[mikdore]

I so feel the last point, and I'd like to add, that not having [as of now] any pattern matching really hurts when working with all sorts of sum types. Coming from Rust, something like `tl::expected` and `Result` feel like night and day.

[grandinj]

I guess people's experiences are different :-)

I find exceptions to be a perfectly fine error handling mechanism.

I certainly prefer it to cluttering my code with explicit checks for return codes and such like.

[dnautics]

returning errors doesn't have to have cluttered code. Just because Go messed it up doesn't mean it's bad.