5 ms·

Please for the love of god no. Go is awesome for its simplicity. Errors should not be abstracted out of handling convenience. Errors are just values either el

Please for the love of god no. Go is awesome for its simplicity. Errors should not be abstracted out of handling convenience. Errors are just values either eliminate the need for the error or handle it like you would any other value. Stop trying to make go work like every other language.

axaxs 7y ago
Agreed. This is the hill I'll die on. Boring error handling is what I specifically love about Go...
- mwaitjmp 7y ago
  Out of interest, how about the proposed check and handle changes proprosed for v2? Details here: https://dev.to/deanveloper/go-2-draft-error-handling-3loo https://dev.to/deanveloper/go-2-draft-error-handling-3loo
  - axaxs 7y ago
    Still not a fan. These seem like schemes for people who are annoyed by errors, and just throw them over the wall... similar to say putting an entire python block in a try/except. With any sufficiently large application you start to realize how awful that is, especially when something fails and the only log is 'EOF'. I've learned to treat errors as first class citizens, because they are. I always add an annotation and stack entry via wrappers before returning them. Unless I'm missing something, that seems all but impossible with these schemes.
    - deleted 7y ago
      [deleted]
grey-area 7y ago
This isn’t a replacement for go error handling, it’s a complement. Sometimes you don’t need to do anything other than pass an error up the chain.
- ajcodez 7y ago
  I would rather every developer takes a second while writing out “if err != nil” to decide how to add context or maybe return a new error with useful metadata.
  - grey-area 7y ago
    It's not really about being lazy, sometimes there is nothing useful to add. I removed some error annotations the other day as they were just cluttering logs without adding usefully to an error for farther down the call stack. Sometimes you don't need to annotate/wrap.
    - ajcodez 7y ago
      Yeah that’s something you can decide too, while typing it out. It’s not about having extra context every time, it’s about deciding. Sometimes you want to ignore the error and take the zero value. Adding try to the language creates a new path of least resistance that decreases code quality.
      - grey-area 7y ago
        You can't decide to avoid the boilerplate though at the moment, because there is no try. You can only type out the boilerplate, and read it, even if you don't really need it in that particular instance. It would not reduce code quality if used in instances where it replaces return nil, err - which is what it is intended for. It's not intended to replace wrapped errors, or error handling, it's intended to replace 3 lines of boilerplate with one word - in the cases where you want to push the error one level up the call stack. Having used go extensively for the last 5 years and built some large projects with it, I disagree this is not useful. I think it's a good proposal in the spirit of go and should be adopted. I'd prefer this as a keyword myself, but of the 6 million instances of if err != nil on github, I think around half could be eliminated by this pattern, so I think it would be useful, if not overused. https://github.com/search?l=Go&q=if+err+%21%3D+nil+%7B&type=Code https://github.com/search?l=Go&q=if+err+%21%3D+nil+%7B&type=...
deleted 7y ago
[deleted]

axaxs 7y ago

Agreed. This is the hill I'll die on. Boring error handling is what I specifically love about Go...

mwaitjmp 7y ago
Out of interest, how about the proposed check and handle changes proprosed for v2? Details here: https://dev.to/deanveloper/go-2-draft-error-handling-3loo https://dev.to/deanveloper/go-2-draft-error-handling-3loo
- axaxs 7y ago
  Still not a fan. These seem like schemes for people who are annoyed by errors, and just throw them over the wall... similar to say putting an entire python block in a try/except. With any sufficiently large application you start to realize how awful that is, especially when something fails and the only log is 'EOF'. I've learned to treat errors as first class citizens, because they are. I always add an annotation and stack entry via wrappers before returning them. Unless I'm missing something, that seems all but impossible with these schemes.
  - deleted 7y ago
    [deleted]

grey-area 7y ago

This isn’t a replacement for go error handling, it’s a complement. Sometimes you don’t need to do anything other than pass an error up the chain.

ajcodez 7y ago
I would rather every developer takes a second while writing out “if err != nil” to decide how to add context or maybe return a new error with useful metadata.
- grey-area 7y ago
  It's not really about being lazy, sometimes there is nothing useful to add. I removed some error annotations the other day as they were just cluttering logs without adding usefully to an error for farther down the call stack. Sometimes you don't need to annotate/wrap.
  - ajcodez 7y ago
    Yeah that’s something you can decide too, while typing it out. It’s not about having extra context every time, it’s about deciding. Sometimes you want to ignore the error and take the zero value. Adding try to the language creates a new path of least resistance that decreases code quality.
    - grey-area 7y ago
      You can't decide to avoid the boilerplate though at the moment, because there is no try. You can only type out the boilerplate, and read it, even if you don't really need it in that particular instance. It would not reduce code quality if used in instances where it replaces return nil, err - which is what it is intended for. It's not intended to replace wrapped errors, or error handling, it's intended to replace 3 lines of boilerplate with one word - in the cases where you want to push the error one level up the call stack. Having used go extensively for the last 5 years and built some large projects with it, I disagree this is not useful. I think it's a good proposal in the spirit of go and should be adopted. I'd prefer this as a keyword myself, but of the 6 million instances of if err != nil on github, I think around half could be eliminated by this pattern, so I think it would be useful, if not overused. https://github.com/search?l=Go&q=if+err+%21%3D+nil+%7B&type=Code https://github.com/search?l=Go&q=if+err+%21%3D+nil+%7B&type=...

deleted 7y ago

[deleted]