4 ms·

Four, actually, but two have been removed for brevity.

rakyll 10y ago
Two. The URL is a constant that is guaranteed not to return an error. It is not brevity. Anyways, the point is I don't understand the point of err != nil bashing here, given there are two programs in the article that only contain one error check each.
- ben_jones 10y ago
  As someone who writes a lot of Go I have mixed feelings about it. The problem is that there are implicit errors regardless and the explicitness in err != nil tricks beginners into thinking that they've covered all edge cases, they haven't. Recover() is probably the only way to handle internal panics and even then it only works if you know to that internal call might call panic(). That said I can't think of an alternative other then to reduce the number of panic()s hidden in various libraries.
  - rakyll 10y ago
    Avoiding error checking against a properly formatted constant is not avoiding error checking. I cannot follow your argument.
    - ben_jones 10y ago
      Sorry, I guess I'm not really making one. If anything I'm commenting that (IMO) explicit error handling isn't as explicit as people thing it is. There are internal errors induced by panic() that are really inconvenient.
      - mixedCase 10y ago
        Panics are supposed to be launched on an "end all work on this; code path is FUBAR". On a web server that usually means dropping the connection, logging everything and firing an automated e-mail to the dev team to notify there's a bug in the code that needs to be fixed. All other error conditions are expected and handled. That's what Go's error handling philosophy is all about.
      - jimjimjim 10y ago
        panic should be a "the world is ending" sort of operation.
- justinsb 10y ago
  This is turning into a major tangent, but where is the guarantee documented?
randomdata 10y ago
Are you referring to the instances where error is a return value, but an error result under the known inputs would be impossible, so it would be pointless to check it? That's not exactly the same as removed for brevity.
- justinsb 10y ago
  Yes - just my quirky sense of humor! It isn't being documented as being safe (that I could find), so it should be checked IMO.
  - randomdata 10y ago
    Does the Go standard library document that on any function like you are expecting? The code for both functions make it pretty clear that an error will only be returned if the input is invalid, which is not something that will occur with the known constants being fed into them.
    - justinsb 10y ago
      Yes, it does, where the guarantee exists: e.g. https://golang.org/pkg/bytes/#Buffer.Write https://golang.org/pkg/bytes/#Buffer.Write Looking at the implementation is no guarantee that the implementation won't be changed in future.
      - randomdata 10y ago
        > Yes, it does, where the guarantee exists That isn't quite the same thing. That says that an error is returned only because it is required to conform to the io.Writer interface. Without that requirement, it wouldn't return error in the first place. It tells the reader that they should not be confused as to why writing to a buffer might return an error, when such an operation should fundamentally not return an error. These other functions in question have very good reasons to return an error: Invalid input. > Looking at the implementation is no guarantee that the implementation won't be changed in future. The Go compatibility promise says that the behaviour won't change, except under exceptional circumstances – like a security flaw that cannot be fixed using the original behaviour. It is highly unlikely that is an issue for those particular functions. But, if you still think it is important, what do you plan to do with an error that might just randomly appear in the future anyway?

Two. The URL is a constant that is guaranteed not to return an error. It is not brevity. Anyways, the point is I don't understand the point of err != nil bashing here, given there are two programs in the article that only contain one error check each.

ben_jones 10y ago
As someone who writes a lot of Go I have mixed feelings about it. The problem is that there are implicit errors regardless and the explicitness in err != nil tricks beginners into thinking that they've covered all edge cases, they haven't. Recover() is probably the only way to handle internal panics and even then it only works if you know to that internal call might call panic(). That said I can't think of an alternative other then to reduce the number of panic()s hidden in various libraries.
- rakyll 10y ago
  Avoiding error checking against a properly formatted constant is not avoiding error checking. I cannot follow your argument.
  - ben_jones 10y ago
    Sorry, I guess I'm not really making one. If anything I'm commenting that (IMO) explicit error handling isn't as explicit as people thing it is. There are internal errors induced by panic() that are really inconvenient.
    - mixedCase 10y ago
      Panics are supposed to be launched on an "end all work on this; code path is FUBAR". On a web server that usually means dropping the connection, logging everything and firing an automated e-mail to the dev team to notify there's a bug in the code that needs to be fixed. All other error conditions are expected and handled. That's what Go's error handling philosophy is all about.
    - jimjimjim 10y ago
      panic should be a "the world is ending" sort of operation.
justinsb 10y ago
This is turning into a major tangent, but where is the guarantee documented?

randomdata 10y ago

Are you referring to the instances where error is a return value, but an error result under the known inputs would be impossible, so it would be pointless to check it? That's not exactly the same as removed for brevity.

justinsb 10y ago
Yes - just my quirky sense of humor! It isn't being documented as being safe (that I could find), so it should be checked IMO.
- randomdata 10y ago
  Does the Go standard library document that on any function like you are expecting? The code for both functions make it pretty clear that an error will only be returned if the input is invalid, which is not something that will occur with the known constants being fed into them.
  - justinsb 10y ago
    Yes, it does, where the guarantee exists: e.g. https://golang.org/pkg/bytes/#Buffer.Write https://golang.org/pkg/bytes/#Buffer.Write Looking at the implementation is no guarantee that the implementation won't be changed in future.
    - randomdata 10y ago
      > Yes, it does, where the guarantee exists That isn't quite the same thing. That says that an error is returned only because it is required to conform to the io.Writer interface. Without that requirement, it wouldn't return error in the first place. It tells the reader that they should not be confused as to why writing to a buffer might return an error, when such an operation should fundamentally not return an error. These other functions in question have very good reasons to return an error: Invalid input. > Looking at the implementation is no guarantee that the implementation won't be changed in future. The Go compatibility promise says that the behaviour won't change, except under exceptional circumstances – like a security flaw that cannot be fixed using the original behaviour. It is highly unlikely that is an issue for those particular functions. But, if you still think it is important, what do you plan to do with an error that might just randomly appear in the future anyway?