Feedback from the Gripes and Wishes Campaign

[IGotD-]

On Monday, 29 May 2023 at 21:18:23 UTC, Ernesto Castellotti wrote:
>
> Mainly because exceptions are often used for errors that aren't 
> really exceptional", I often found myself having to handle 
> exceptions (mostly in Java and C++) that really didn't give a 
> damn and just abort the program.
>
> I have rarely seen exceptions handled well by programmers other 
> than in C++ code done by really experienced programmers, I much 
> prefer error handling like Rust and Go ie with multi-value 
> returns, in my experience I have always found this technique 
> leads to much better error handling than using exceptions. 
> (https://go.dev/doc/faq#exceptions, 
> https://go.dev/blog/error-handling-and-go, 
> https://doc.rust-lang.org/book/ch09-00-error-handling.html)

Interesting observation. I presume you are talking about the 
syntax of exceptions that is triggering this drawback, because 
some newer languages have exceptions like Swift but isn't really 
exceptions underneath but more Rust like return values.

I must say that I in C++ often use return values rather than 
exceptions and even return enums. Now when you write this I 
haven't really reflected on this. I just wonder why do I do this? 
I think the answer is that they are simple and stupid.

Also I seen in a professional C++ environment that programmers 
tend to use exception incorrectly. For example they tend to catch 
all exceptions even if that isn't correct as they don't handle 
all exceptions. If a specific exception isn't handled, the 
program should exit.

This doesn't mean I'm against exceptions, I think exceptions are 
a very good error handling mechanism that allow inheritance thus 
expanding on existing error structures. Rust doesn't handle this 
well I think. Swift expanded upon the error handling of Rust and 
filled this gap.

The question remains, is it the syntax or the underlying error 
handling mechanism that prevents programmers from using 
exceptions correctly?