6 ms·

Whenever they fix the tremendous issue of errors being ignored by default, give me a call.

by knocte 13y ago

MindTwister 13y ago
Could you expand on this? I'm not sure I follow.
- howeyc 13y ago
  I think what GP is getting at that if you call a function with one return value, you can ignore it by not assigning anything to the result of the function. http://play.golang.org/p/9J46QRHul1 http://play.golang.org/p/9J46QRHul1 They presumably would like to force you to use the return value if it is of type error.
  - MindTwister 13y ago
    Ah, got it. I thought it was way more sinister than that. On a side note, does any programming languages force you to use the return value of every function call?
    - Shish2k 13y ago
      Go forces you to either assign the return value to a variable and then use that variable, or pretend it doesn't exist at all. I think they were trying to get rid of the middle "assign it to a variable, deal with it later" case, to encourage people to write error-handling code there and then, but I've found that instead it pushes me towards completely ignoring error codes, then because there's no "unused variable 'errorCode'" warning, I forget to go back and robustify the code :( I probably /should/ get into the habit of writing error-handling code at the same time as writing the main-path code, but for someone who's just started learning the language and just wants to see what works, I find it really frustrating >_<
      - sambeau 13y ago
        You soon get used to the pattern: blah, err := foo(...) if err != nil { return nil, err } and it's sister: blah, err := foo(wibble) if err != nil { return nil, errors.New("foo error with blah due to: " + wibble) } After a while I got to like passing errors carefully back up the call stack , cleaning them up, rewriting them and making them more useful. My Go programs have far better (more detailed & relevant) error messages than any of my other code.
        masklinn 13y ago
        > You soon get used to the pattern: Yes, we all know how good humans are at work which no computer could ever do such as repetitive output of pointless generic boilerplate.
        sambeau 13y ago
        My point is that translating an error from one call to the previous is neither generic nor pointless. An exception and line-number (and a call-stack dump) is great for a developer, but a good textual error message is needed for a real user.
        zellyn 13y ago
        I agree with sambeau on this one. I have come to like the go way of doing things: it's extremely simple, doesn't take much thought, and after a little while is very easy to read.
        masklinn 13y ago
        > My point is that translating an error from one call to the previous is neither generic nor pointless. The first pattern does not do that. The second one is still mostly pointless generic boilerplate: blah, err := if err != nil { return nil, errors.New() } is all boilerplate, only two parts are not: the call itself and the error message. > An exception and line-number (and a call-stack dump) is great for a developer, but a good textual error message is needed for a real user. 1. having exceptions doesn't preclude handling them and writing user-readable error messages 2. exceptions are not the only alternative to C-style error handling
    - pcwalton 13y ago
      OCaml gives you a warning ("this function should return unit") if you don't use the result of each function call, unless that function returns unit (void). You can suppress it with the "ignore" function or with "let _ = some_function() in …" I would like to implement this feature in Rust as well, as it would have saved me hours of debugging a couple of times.
      - masklinn 13y ago
        > OCaml gives you a warning ("this function should return unit") if you don't use the result of each function call, unless that function returns unit (void). You can suppress it with the "ignore" function or with "let _ = some_function() in …" GHC can also do so optionally (with -fwarn-unused-do-bind) (and I'm unsure there even is a way to ignore return values outside of do blocks)
- fauigerzigerk 13y ago
  He probably wants exceptions.
coldtea 13y ago
Whenever that issues does become "tremendous" (seriously?), give me a call...
JulienSchmidt 13y ago
I don't think this should be the default behavior since you would end up writing a lot of boilerplate _ = myFunc() code. But it would be nice if the vet tool had a (optional) feature to warn you about ignored return values.
brianbarker 13y ago
Sounds like the oft-repeated cry of the C-based language dev in regards to a lack of exceptions in Go. The blog and comments here have summed this debate up nicely: http://uberpython.wordpress.com/2012/09/23/why-im-not-leaving-python-for-go/ http://uberpython.wordpress.com/2012/09/23/why-im-not-leavin...
- bsg75 13y ago
  Linked in that article (http://benchmarksgame.alioth.debian.org/u64q/code-used-time-used-shapes.php http://benchmarksgame.alioth.debian.org/u64q/code-used-time-...) is a comparison of conciseness and performance. Interesintgly the FP languages are put in a right-more / less-concise column than Go, C, C++ (unless I am reading it wrong). Since the verbosity of error handling in Go is part of the debate here, are not FP languages often more concise? Is "concise-ness" really an issue?

Whenever they fix the tremendous issue of errors being ignored by default, give me a call.

by knocte 13y ago

Whenever they fix the tremendous issue of errors being ignored by default, give me a call.

MindTwister 13y ago

Could you expand on this? I'm not sure I follow.

howeyc 13y ago
I think what GP is getting at that if you call a function with one return value, you can ignore it by not assigning anything to the result of the function. http://play.golang.org/p/9J46QRHul1 http://play.golang.org/p/9J46QRHul1 They presumably would like to force you to use the return value if it is of type error.
- MindTwister 13y ago
  Ah, got it. I thought it was way more sinister than that. On a side note, does any programming languages force you to use the return value of every function call?
  - Shish2k 13y ago
    Go forces you to either assign the return value to a variable and then use that variable, or pretend it doesn't exist at all. I think they were trying to get rid of the middle "assign it to a variable, deal with it later" case, to encourage people to write error-handling code there and then, but I've found that instead it pushes me towards completely ignoring error codes, then because there's no "unused variable 'errorCode'" warning, I forget to go back and robustify the code :( I probably /should/ get into the habit of writing error-handling code at the same time as writing the main-path code, but for someone who's just started learning the language and just wants to see what works, I find it really frustrating >_<
    - sambeau 13y ago
      You soon get used to the pattern: blah, err := foo(...) if err != nil { return nil, err } and it's sister: blah, err := foo(wibble) if err != nil { return nil, errors.New("foo error with blah due to: " + wibble) } After a while I got to like passing errors carefully back up the call stack , cleaning them up, rewriting them and making them more useful. My Go programs have far better (more detailed & relevant) error messages than any of my other code.
      - masklinn 13y ago
        > You soon get used to the pattern: Yes, we all know how good humans are at work which no computer could ever do such as repetitive output of pointless generic boilerplate.
        sambeau 13y ago
        My point is that translating an error from one call to the previous is neither generic nor pointless. An exception and line-number (and a call-stack dump) is great for a developer, but a good textual error message is needed for a real user.
        zellyn 13y ago
        I agree with sambeau on this one. I have come to like the go way of doing things: it's extremely simple, doesn't take much thought, and after a little while is very easy to read.
        masklinn 13y ago
        > My point is that translating an error from one call to the previous is neither generic nor pointless. The first pattern does not do that. The second one is still mostly pointless generic boilerplate: blah, err := if err != nil { return nil, errors.New() } is all boilerplate, only two parts are not: the call itself and the error message. > An exception and line-number (and a call-stack dump) is great for a developer, but a good textual error message is needed for a real user. 1. having exceptions doesn't preclude handling them and writing user-readable error messages 2. exceptions are not the only alternative to C-style error handling
  - pcwalton 13y ago
    OCaml gives you a warning ("this function should return unit") if you don't use the result of each function call, unless that function returns unit (void). You can suppress it with the "ignore" function or with "let _ = some_function() in …" I would like to implement this feature in Rust as well, as it would have saved me hours of debugging a couple of times.
    - masklinn 13y ago
      > OCaml gives you a warning ("this function should return unit") if you don't use the result of each function call, unless that function returns unit (void). You can suppress it with the "ignore" function or with "let _ = some_function() in …" GHC can also do so optionally (with -fwarn-unused-do-bind) (and I'm unsure there even is a way to ignore return values outside of do blocks)
fauigerzigerk 13y ago
He probably wants exceptions.

coldtea 13y ago

Whenever that issues does become "tremendous" (seriously?), give me a call...

JulienSchmidt 13y ago

I don't think this should be the default behavior since you would end up writing a lot of boilerplate _ = myFunc() code. But it would be nice if the vet tool had a (optional) feature to warn you about ignored return values.

brianbarker 13y ago

Sounds like the oft-repeated cry of the C-based language dev in regards to a lack of exceptions in Go. The blog and comments here have summed this debate up nicely: http://uberpython.wordpress.com/2012/09/23/why-im-not-leaving-python-for-go/ http://uberpython.wordpress.com/2012/09/23/why-im-not-leavin...

bsg75 13y ago
Linked in that article (http://benchmarksgame.alioth.debian.org/u64q/code-used-time-used-shapes.php http://benchmarksgame.alioth.debian.org/u64q/code-used-time-...) is a comparison of conciseness and performance. Interesintgly the FP languages are put in a right-more / less-concise column than Go, C, C++ (unless I am reading it wrong). Since the verbosity of error handling in Go is part of the debate here, are not FP languages often more concise? Is "concise-ness" really an issue?