> As I established a more Go-minded approach, it became much more pleasant.
Could you explain more by any chance?
Could you explain more by any chance?
You, the writer, pass around errors manually so that the reader, who interfaces with the code 10x more than the writer, is able to reason about the code. Go's errors handling sucks, but I don't think everyone has the same opinion on why it sucks; I personally think that sum types should be added to the language making it impossible for errors to be silently ignored.
Exceptions, while convenient, require too much discipline to use cleanly.
Here is a link to Google's C++ style guide, which discourages exceptions with pros & cons:
https://google.github.io/styleguide/cppguide.html#Exceptions
It's your 25 years of coding, vs the several thousand man-months of Google's C++ codebase. That said, I don't deny that some people use exceptions with little mental overhead. I've been told about very high performance and readable trading software that made use of exceptions. My main gripe is that it they require discipline to use correctly, almost everyone uses them differently, and they make code harder to reason about. I would prefer a language that doesn't need an IDE to locally reason about some piece of code.
They concluded against them due to problems integrating into legacy code which is fair enough
And don’t forget the principle use case of C++ - it is a low level language. While exceptions are pretty cheap overall, they can be expensive in some niche cases which do happen more often in C++ than in python.
I really haven’t heard a good case against exceptions per se — they make it possible to handle every error at an appropriate place. And bubbling the error up to possibly a much higher place is exactly the needed approach many times (e.g. returning a http error code on an unrecoverable mistake)
I think most of the time the real answer is to not have so many errors. You shouldn't return errors when API users make mistakes (as Java does); you should panic. You shouldn't return errors when something is "missing" (as Python does); you should return a zero value, and that zero value should sometimes still be useful.
In general you should be trying to write total functions, and picking your types so you can write total functions, and panicking rather than erroring if your preconditions are violated.