3 ms·

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 implementat

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?
- wtbob 10y ago
  > 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? Terminate processing and pass the error back up the call chain. This is basically what exceptions do, and basically what 'if err != nil { return err }' does. One could also pause processing, interrogate the call chain for what to do about the error condition and the proceed as directed; this is what conditions & restarts do. IMHO it's a better solution, but it requires some syntax to be readable.
  - randomdata 10y ago
    > Terminate processing and pass the error back up the call chain. This is basically what exceptions do, and basically what 'if err != nil { return err }' does. The function in question that could return an error is being called in the main function. Who are you going to pass it to, exactly? error is a not a return value on main. If you knew what the error could be, you might find a suitable workaround under those conditions. But since the error does not even exist for you to handle, about all you can do is terminate the application. Which is exactly what will happen in this circumstance anyway, even if you don't check the error result. I'm still not clear what you are really going to meaningfully do with the error information here even if you did magically start getting errors against the compatibility promise? If you are going to handle errors, you actually have to know what you want to do with them. The following adds nothing to your code. if err != nil { // I didn't expect that. Oh well. } It's not like anyone is suggesting you should avoid checking errors in all circumstances. We're talking about very specific cases where all of the conditions are known. If GET stops being an HTTP request method, or http://example.com/ http://example.com/ is no longer a valid URL, you've got way bigger problems than not gracefully handling the world flipping upside down.
    - wtbob 10y ago
      > The function in question that could return an error is being called in the main function. Who are you going to pass it to, exactly? The operating system: exit with a non-zero exit code, indicating the specific error.
      - randomdata 10y ago
        Which is exactly what will happen as the code is written.

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?

wtbob 10y ago
> 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? Terminate processing and pass the error back up the call chain. This is basically what exceptions do, and basically what 'if err != nil { return err }' does. One could also pause processing, interrogate the call chain for what to do about the error condition and the proceed as directed; this is what conditions & restarts do. IMHO it's a better solution, but it requires some syntax to be readable.
- randomdata 10y ago
  > Terminate processing and pass the error back up the call chain. This is basically what exceptions do, and basically what 'if err != nil { return err }' does. The function in question that could return an error is being called in the main function. Who are you going to pass it to, exactly? error is a not a return value on main. If you knew what the error could be, you might find a suitable workaround under those conditions. But since the error does not even exist for you to handle, about all you can do is terminate the application. Which is exactly what will happen in this circumstance anyway, even if you don't check the error result. I'm still not clear what you are really going to meaningfully do with the error information here even if you did magically start getting errors against the compatibility promise? If you are going to handle errors, you actually have to know what you want to do with them. The following adds nothing to your code. if err != nil { // I didn't expect that. Oh well. } It's not like anyone is suggesting you should avoid checking errors in all circumstances. We're talking about very specific cases where all of the conditions are known. If GET stops being an HTTP request method, or http://example.com/ http://example.com/ is no longer a valid URL, you've got way bigger problems than not gracefully handling the world flipping upside down.
  - wtbob 10y ago
    > The function in question that could return an error is being called in the main function. Who are you going to pass it to, exactly? The operating system: exit with a non-zero exit code, indicating the specific error.
    - randomdata 10y ago
      Which is exactly what will happen as the code is written.