Comment by forrestthewoods
11 hours ago
> You really don't. Like I said, it's kind of the whole point of exceptions.
No, this is actually just wrong. With exceptions you “don’t have to think about” the exception getting caught by some higher level catch.
But you do have to think about it in the sense that every single line in your code could unwind. Which makes ensuring you remain in a valid state more difficult.
One of the issues with exceptions isn’t the throw. It’s what do you do after you catch.
> That a tool can be misused doesn't delegitimize the tool.
I’m always open to the possibility that if something I’ve seen has been bad 100 times then on the 101st it might be good. But at some point you really just have to call a spade a spade.
>But you do have to think about it in the sense that every single line in your code could unwind.
No, this is actually just wrong. There is code that can throw, and there is code that cannot possibly throw. The way you write exception-safe code is by not holding manually-managed resources (e.g. raw pointers that own heap allocations, or file descriptors that must be close()d, or anything else that needs cleanup code that has not been put in a destructor) during sections that may throw. In other words, use RAII to manage your resources, regardless of whether exceptions may be thrown.
Program state is significantly more complex than just needing some RAII resources to cleanup via destructors.
> during sections that may throw
Yeah one of the problems with exceptions is it’s impossible to know what “may throw” other than “well I guess literally anything so everything”. It is very irritating.
At the end of the day exceptions are just a little syntactic sugar. Or perhaps syntactic bitters.
It is notable that systems languages designed after C++ all chose to not include exceptions. Go, Zig, Swift, Odin, Jai.
Rust panics are kinda sorta exceptions in that they unwind. But their intended use case is for irrecoverable errors. And of course you can set panic=abort.
C++ exceptions are very rarely treated as so serious module level irrecoverability.
>Program state is significantly more complex than just needing some RAII resources to cleanup via destructors.
You're being rather vague. All throwing does is cause control flow to jump to the nearest catch that can handle the exception, destructing all objects along the way. I struggle to think of an example that could cause problems that isn't some variation of "I had some code after the exception that I needed to run, and it didn't run, because it wasn't set up to run at scope exit". I'd love to see such an example if you have one.
>it’s impossible to know what “may throw”
* If it's a throw statement, it may throw.
* If it's an expression that contains a 'new' operator, it may throw.
* If it's an expression that contains a dynamic_cast to a reference type, it may throw.
* If it calls a function that you don't know that it does not do any of the above, it may throw.
* If it's unknown if a function is called (e.g. types are templated), it may throw.
* Otherwise, it doesn't throw.
If you're managing resources manually, either make sure not to call any functions until you release them, or stop managing them manually. I encourage the latter.
9 replies →