6 ms·

Heh, it does feel repetitive. But after ~10 years with Java, I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exce

by rpercy 10y ago

Heh, it does feel repetitive. But after ~10 years with Java, I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception. Obviously, there's no perfect solution, and preference is subjective.

stefano 10y ago
It's the same cognitive load, really. Instead of deciding how to best propagate exceptions, you're now deciding how to best propagate the error value.
- rpercy 10y ago
  Not really. In a language like Java, some of the questions I'd have to ask myself are: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Should I throw a checked or unchecked exception? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) In golang, I know there's really just the one pattern: check if err != nil, prepend a descriptive message, and return it.
  - Groxx 10y ago
    >check if err != nil, prepend a descriptive message, and return it. That'd be the RuntimeException equivalent, sure. But what do you do for the equivalent of checked exceptions? Errors are frequently recoverable, "err != nil" alone does nothing to help you there, and string manipulation is a horrific alternative to types.
    - cdelsolar 10y ago
      You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.
      - Groxx 10y ago
        At which point you're back to the original complaint of: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) (except for "- Should I throw a checked or unchecked exception?" since that's fairly Java-specific) To me, those questions seem unavoidable, and sweeping them under the rug is a false simplicity. You're exposing things - what do you expose? How should the caller deal with it? Is it the same as [other thing]? I'd much rather have the type system involved, since error handling is pretty critical to correctness/stability. If go's giving up the safety, what does it get in return?
        XorNot 10y ago
        I feel like the type system is involved? If there's a problem it's that Go doesn't make throwing typed errors a common convention (and we lack the tooling to make handling them a habit I.e. inspect this call and find me all the error types which can come back.
candiodari 10y ago
In reality Go makes it worse, if you truly keep track of all possible cases. After calling a method, in Go you have to 1) "if err != nil" after every statement 2) give some serious thought to whether the previous statement could panic or not Good luck if it's a library call that may get updated or call other libraries ! 3) Think about the non-error error cases that can't be abstracted out. Go is like C, in the sense that there is an ERETRY "error" (unsurprisingly, you should simply try again, you should NOT fail) And there are cases where there can be an error and yet error is nil. Easy example of this would be sscanf. And we now see practical Go code published online : how these problems are dealt with, real world edition: 1) either mindlessly putting "if err != nil { return err }", which is a very bad information-erasing exception system, or just outright ignoring errors. Don't you know you can also use "_" as the error variable ? Maybe they should make that implicit like in perl. Of course perl is likely to tell you this happened ... unlike C and Go. (really brings back the C days doesn't it ?) 2) most people either don't know or just deny this. Thankfully panics at least do list where they occur. They also kill your program and print stacktraces. Pages and pages and pages of stacktraces. 3) very few people even know about these problems ... so they're ignored, and the standard Go tools themselves don't behave according to unix specifications.
- cube2222 10y ago
  Panic is pretty much never used (so you don't really have to think if the previous statement can panic. If it does it means something is SO wrong that your application can't continue anyways because it's broken) You should really use a library like github.com/pkg/errors so you get to wrap the error you return with additional information. Errors are just a worse Either monad after allm they're much more pleasant to use than exceptions.
  - geoka9 10y ago
    > Panic is pretty much never used (so you don't really have to think if the previous statement can panic. If it does it means something is SO wrong that your application can't continue anyways because it's broken) That's it. I think OP just assumed panics in Go are what exceptions are in other languages.
hota_mazi 10y ago
> I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception This is like saying "I'm happy to avoid the cognitive load of having to specify how my code should behave in case of an error". Sure, your code is simpler as a result. It's also more buggy.

by rpercy 10y ago

stefano 10y ago

It's the same cognitive load, really. Instead of deciding how to best propagate exceptions, you're now deciding how to best propagate the error value.

rpercy 10y ago
Not really. In a language like Java, some of the questions I'd have to ask myself are: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Should I throw a checked or unchecked exception? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) In golang, I know there's really just the one pattern: check if err != nil, prepend a descriptive message, and return it.
- Groxx 10y ago
  >check if err != nil, prepend a descriptive message, and return it. That'd be the RuntimeException equivalent, sure. But what do you do for the equivalent of checked exceptions? Errors are frequently recoverable, "err != nil" alone does nothing to help you there, and string manipulation is a horrific alternative to types.
  - cdelsolar 10y ago
    You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.
    - Groxx 10y ago
      At which point you're back to the original complaint of: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) (except for "- Should I throw a checked or unchecked exception?" since that's fairly Java-specific) To me, those questions seem unavoidable, and sweeping them under the rug is a false simplicity. You're exposing things - what do you expose? How should the caller deal with it? Is it the same as [other thing]? I'd much rather have the type system involved, since error handling is pretty critical to correctness/stability. If go's giving up the safety, what does it get in return?
      - XorNot 10y ago
        I feel like the type system is involved? If there's a problem it's that Go doesn't make throwing typed errors a common convention (and we lack the tooling to make handling them a habit I.e. inspect this call and find me all the error types which can come back.

candiodari 10y ago

In reality Go makes it worse, if you truly keep track of all possible cases. After calling a method, in Go you have to 1) "if err != nil" after every statement 2) give some serious thought to whether the previous statement could panic or not Good luck if it's a library call that may get updated or call other libraries ! 3) Think about the non-error error cases that can't be abstracted out. Go is like C, in the sense that there is an ERETRY "error" (unsurprisingly, you should simply try again, you should NOT fail) And there are cases where there can be an error and yet error is nil. Easy example of this would be sscanf. And we now see practical Go code published online : how these problems are dealt with, real world edition: 1) either mindlessly putting "if err != nil { return err }", which is a very bad information-erasing exception system, or just outright ignoring errors. Don't you know you can also use "_" as the error variable ? Maybe they should make that implicit like in perl. Of course perl is likely to tell you this happened ... unlike C and Go. (really brings back the C days doesn't it ?) 2) most people either don't know or just deny this. Thankfully panics at least do list where they occur. They also kill your program and print stacktraces. Pages and pages and pages of stacktraces. 3) very few people even know about these problems ... so they're ignored, and the standard Go tools themselves don't behave according to unix specifications.

cube2222 10y ago
Panic is pretty much never used (so you don't really have to think if the previous statement can panic. If it does it means something is SO wrong that your application can't continue anyways because it's broken) You should really use a library like github.com/pkg/errors so you get to wrap the error you return with additional information. Errors are just a worse Either monad after allm they're much more pleasant to use than exceptions.
- geoka9 10y ago
  > Panic is pretty much never used (so you don't really have to think if the previous statement can panic. If it does it means something is SO wrong that your application can't continue anyways because it's broken) That's it. I think OP just assumed panics in Go are what exceptions are in other languages.

hota_mazi 10y ago

> I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception This is like saying "I'm happy to avoid the cognitive load of having to specify how my code should behave in case of an error". Sure, your code is simpler as a result. It's also more buggy.