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.
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.
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.
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.
