> Besides: exactly the same bug can occur in Rust, because panics. On the panic path, your cleanup() won't be called. And with "?", it's also easy to forget to call cleanup(), because "?" acts just like rethrowing an exception.

It's harder. If you're typing ?, you're aware that you're dealing with a result or option (with the values of the error case clearly documented in the type system), and aware of the fact that you might be returning early, and have forced your own function's signature to also be a result or option.

In contrast, I've had code where finger->Position.X occasionally threw. Because a finger was released, invalidating the old finger ID, before it even gave you the chance to process the finger up event to realize you shouldn't query that finger. Did you know you need to wrap every finger position query in a try/catch? I didn't, so this was just a rare crash bug for awhile. What exception did I catch? I don't remember (but not a null reference nor an access violation exception), and it's not documented, so in new code I guess I'd just try { ... } catch (Platform::Exception^) {} despite the fact that we all know catch-all do-nothing statements are terrible. At least I can minimize the scope!

For bonus points, the exception handling overhead was heavy enough that the framerate of the game we were working on would stutter if you pawed at the touch screen. Better than crashing, but still terrible. Not having source access to the throwing code, and touch release events being delayed, this was the least horrible option available though. Yaaaay.

Was this a nasty edge case and not indicative of all use of exceptions? Yes. Do I eventually encounter such a nasty edge case in most, if not all, large scale projects involving exceptions in practice? Also yes. Often enough that it influences my preferred error handling mechanisms, even.

Do I encounter such a nasty edge case in return based error handling? Not in the wild. The use of error codes makes it much clearer what can fail. On the rare occasion I've encounter something similar, it's been when harshly stress testing cross platform API abstractions in contrived tests, when disambiguating between multiple error codes. Occasionally, the underlying API does something strange and returns an unexpected error code (either a unique error code, or one of the usual error codes in unusual circumstances) and I take a suboptimal error handling path.

Usually, at worst, the end user would've need to retry something, even if I hadn't caught and worked around the underlying API weirdness.

> Exceptions, in practice, produce clear code.

Do you catch NullReferenceException s instead of writing basic if conditionals to check values for null? Probably not. For such unexceptional cases it's less clear (which reference, exactly, was null?), and the performance overhead is often unacceptable.

For more exceptional uses of exceptions, you can sometimes get clearer code. It's often brittle and mishandles rare edge cases, but it's clearer for the happy path at least. But I will happily sacrifice a little of that clarity to make that code handle the edge cases properly instead of crashing - because those exceptional cases aren't really all that exceptional after all.