5 ms·

I agree with your pointa. A note though, I also used to think exceptions are "essential", but after working with code that forbids exceptions and uses explicit

by yati 7y ago

I agree with your pointa. A note though, I also used to think exceptions are "essential", but after working with code that forbids exceptions and uses explicit error status passing, I find exceptions very awkward to work with. I find them a very lazy way of doing error propagation, which in turn encourages lazy error handling.

erik_seaberg 7y ago
C++ relies heavily on error handling using out-of-band exceptions. f(g(h())) needs h and g to return meaningful values rather than errors, constructors can't return errors at all, and member initializer lists can't check for returned errors. You could make a dialect in which every method returns an error and every object has an init(...) method instead of a ctor, but it would be closer to imperative VB than idiomatic and readable C++.
je42 7y ago
also note that Java has checked exceptions, and a lot of programmers still opt to deal with errors in a lazy way. Same for error codes, go has explicit error, and several programmers still opt to deal with errors in a lazy way. I think the syntax and semantical contructs a language offers doesnt matter much when a lot of programmers dont have time and/or discipline and/or priority to deal with error cases. Error handling is hard. Also, since programmers in general think less about errors, library often dont expose errors in helpful ways and/or well-defined ways.
- dgellow 7y ago
  > Also, since programmers in general think less about errors That's one reason I like Go's approach, even if the boilerplate is ugly. When writing Go code, I'm pushed to think about the `err` returned value. When reading Go code, I know directly how `err` is handled, without any surprise, and if it isn't then that should be for a reason, so something to dig out. While it's quite annoying at first, after some time it becomes quite easy to either mentally filter out the error handling boilerplate (thus focus on the actual logic), or focus on it. Of course, YMMV.
  - yati 7y ago
    There's some boilerplate (a bit less compared to Go) required to deal with errors in Rust too, but additionally, the compiler can enforce you can't get at the return value without dealing with the error variant. I just checked that there are also static checkers for Go that'll tell you if you forgot to check an error.
bastih 7y ago
Both standard library and other libs make use of them, so you often can't just ignore exceptions. Also agree on your point - I'm not saying I like exceptions, I like explicitly passing type-encapsulated results/errors more for clarity. Exceptions happen in a "second invisible lane" right next to the code you are writing, and for example aren't immediately visible when reviewing code.
- jcelerier 7y ago
  > Exceptions happen in a "second invisible lane" right next to the code you are writing, and for example aren't immediately visible when reviewing code. hm, that's interesting - when doing C++ I always see the "bubbling-up" lane

by yati 7y ago

erik_seaberg 7y ago

C++ relies heavily on error handling using out-of-band exceptions. f(g(h())) needs h and g to return meaningful values rather than errors, constructors can't return errors at all, and member initializer lists can't check for returned errors. You could make a dialect in which every method returns an error and every object has an init(...) method instead of a ctor, but it would be closer to imperative VB than idiomatic and readable C++.

je42 7y ago

also note that Java has checked exceptions, and a lot of programmers still opt to deal with errors in a lazy way. Same for error codes, go has explicit error, and several programmers still opt to deal with errors in a lazy way. I think the syntax and semantical contructs a language offers doesnt matter much when a lot of programmers dont have time and/or discipline and/or priority to deal with error cases. Error handling is hard. Also, since programmers in general think less about errors, library often dont expose errors in helpful ways and/or well-defined ways.

dgellow 7y ago
> Also, since programmers in general think less about errors That's one reason I like Go's approach, even if the boilerplate is ugly. When writing Go code, I'm pushed to think about the `err` returned value. When reading Go code, I know directly how `err` is handled, without any surprise, and if it isn't then that should be for a reason, so something to dig out. While it's quite annoying at first, after some time it becomes quite easy to either mentally filter out the error handling boilerplate (thus focus on the actual logic), or focus on it. Of course, YMMV.
- yati 7y ago
  There's some boilerplate (a bit less compared to Go) required to deal with errors in Rust too, but additionally, the compiler can enforce you can't get at the return value without dealing with the error variant. I just checked that there are also static checkers for Go that'll tell you if you forgot to check an error.

bastih 7y ago

Both standard library and other libs make use of them, so you often can't just ignore exceptions. Also agree on your point - I'm not saying I like exceptions, I like explicitly passing type-encapsulated results/errors more for clarity. Exceptions happen in a "second invisible lane" right next to the code you are writing, and for example aren't immediately visible when reviewing code.

jcelerier 7y ago
> Exceptions happen in a "second invisible lane" right next to the code you are writing, and for example aren't immediately visible when reviewing code. hm, that's interesting - when doing C++ I always see the "bubbling-up" lane