It doesn't.
Exercise for the reader: detect evaluation interleaving without exceptions.
> If your code throws so many exceptions that not freeing the memory allocated during that code point becomes a problem
It need not manifest itself as a mere memory leak.
Exercise for the reader: make something happen beside a memory leak.
Yes it does. Of course you can detect different evaluation orders using side effects, but the fact that evaluation order is unspecified isn't generally a problem: if you write code like `a() + b()` and a() and b() has side-effects that depend on the order they're evaluated in, that is just a bad way of writing code. In any language.
The point here is that the compiler is allowed to interleave subexpressions of the two different arguments which causes a memory leak in seemingly safe code. That is a very unreasonable thing for the compiler to do, which is why it is a footgun. But not that it can ONLY happen if the second function throws in between the construction of the object with "new" and the construction of the shared_ptr: if the second function doesn't throw an exception, the construction of shared_ptr is guaranteed to happen.
Incidentally: those "exercise for the reader" comments are incredibly obnoxious.
generally is the key word here.
> if you write code like `a() + b()`
The code doesn't have to look like that. Add e.g. some arguments...
f(**x, g());
> Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function). Where possible, this International Standard defines a set of allowable behaviors. These define the nondeterministic aspects of the abstract machine.
> Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer). [ Note: this International Standard imposes no requirements on the behavior of programs that contain undefined behavior. —end note ]
Unspecified means that you can't rely on the order of evaluation. "Anything" may not happen; the compiler controls the sequencing.
Another favorite “criticism” I have of C++ goes along the lines of “but someone could overload operator+ to be division!” I have only seen that as a contrived critic’s example, or a joke.
Actually, that’s what you are supposed to do, as this is the only way for a constructor to let the caller know that something went wrong.
The factory could return std::optional<Foo> or std::unique_ptr<Foo> or std::variant<Foo, Error> or absl::StatusOr<Foo> .
It's an improvement in terms of code reuse but not in semantic simplification basically.
I'm not sure what you mean. Here's an example with the output from std::optional being unwrapped and put in a struct member: https://godbolt.org/z/Ms4Kar18j
Also there's opt.value_or() which can use a default value in the case opt is nullopt.
>It also replaces an automated and enforced action by the compiler (exception being thrown) by a need for a manual check which feels very 1975
I think remram's goal was to avoid exceptions. So this is a criticism of remram's goal rather than the method to achieve that goal.
Also, std::optional can integrate with exception-producing code because opt.value() throws an exception if opt is nullopt.
And now you have to do this for every type that have some amount of preconditions. I don't understand in which universe this is sane - more code == more bugs.
e.g. here's what one would write with exceptions: https://godbolt.org/z/evMsh6383 (and, to be honest, if one is writing e.g. a command-line tool and not a reactive gui app, most likely https://godbolt.org/z/eW8YM5Gz4 as your OS will catch the thing anyways and then it's just a `coredumpctl gdb` / "open in debugger" away) ; you get the same guarantee of never having an invalid Foo but at much less mental cost.
It also prevents you of having aggregates as all the "parent" owner class will need their own wrapping in optional + private ctor, in case a sub-sub-sub-sub field would fail.
e.g. given
struct DomainObject {
Foo mainFoo;
Foo secondaryFoo;
int whatever;
};
struct GameState {
std::vector<DomainObject> objects;
};
On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless.
IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment.
but it's the whole point ! that's exactly why exceptions are good !
> to a place where there is so little context that the final error message presented to the user is near useless.
there are only two valid cases: there's an error that you know you are able to recover from, you did recover, and the users does not see a message and never knows that an error happened, OR the user sees the message "The program has encountered an error. A backup of your data has been saved in c:/foo/. The program will now exit.".
Anything else makes software terrible to use. If you have logging and recovery to do, use your logging architecture and core dumps, don't misuse exceptions for that.
> On the other hand return values (using something like a try/either monad) have the property of forcing the developer to think about the unhappy path in every layer. Maybe a bit more code, but the quality of diagnostics - priceless.
Except what happens in practice is that people just put panics everywhere because most of the time there is no meaningful action one can take at the layer where the implementation happens. Actual examples in servo: https://pastebin.com/0DAFU9vS
I also invite you to run the following command:
$ cd ~/.cargo
$ rg panic! | wc -l
I've not seen Go code to be meaningfully different either.
> IMHO exceptions/panics should be reserved for bugs only (eg assertions), and return values for all the other error handling caused by user input or environment.
Sure, this is the community consensus in C++. It's the Python people who use exceptions to get out of for loops :)
But the most important rule is that - invalid state must not be representable in the program. There must be no way to get an "invalid" object (unless the object being invalid is part of its possible domain, but this is exceedingly rare when one isn't interfacing with a 1985 C API)
Good for what? For crashing the program with a stacktrace? Probably. But for regular error handling - that's a terrible thing. They break normal control flow by adding a parallel / alternative control flow. Now with them you have to think on what happens if any of the code you call suddenly throws an exception and the number of potential control flow paths increases drastically. They are not referentially transparent and it is nearly impossible to do functional programming with them (they introduce side effects everywhere). You can also end up in a really bad situation when a destructor throws (typically crash).
> I get 2987 as a result. Choosing to program like this instead of using exceptions which at least can be recovered by the person who will use your lib, is literally hateful towards users.
But panics are Rust equivalent of exceptions. That's the whole point of them. They are used for exceptional cases, which are impossible to recover from (which means the only way to deal with is to dump core and terminate) and most of the time preventable (you can always avoid dividing by zero or going out of array bounds).
It looks like we agree they should not be used for regular errors, like e.g. file not found. I'd not like my word processor to terminate with a core dump when it couldn't load the file from the disk. In this case return values are way better error handling mechanism.
> invalid state must not be representable in the program
Returning an option/try/either strikes that goal just as well as exceptions.
No, not really. Either the allocation followed the happy path, or one of the expected failure modes kicked in.
And the supposed footgun example boiled down to failing to handle one of the failure modes.
I mean, think about it: std::make_shared is a factory method, isn't it?
However mind that if you don't throw from C++'s perspective the object is fully created, so that the destructor will run.
If you throw an exception from the contractor, the object won't be fully created.
Yeah there's definitely criticisms you can throw at C++, but this always struck me as stupid. You could also write an `add` method that divides in Java.
I've never liked the idea of 'operators' in the first place, tbh. Scheme opened my eyes in that they're all just procedures. And then with Smalltalk and Scala I saw that they can all just be methods as well.