Hacker News new | ask | show | jobs
by scuff3d 108 days ago
"Here's the uncomfortable truth: a try keyword in Go without fixing the error type is just syntax sugar. You'd get slightly less typing but none of the real benefits - no exhaustiveness checking, no compiler-inferred error sets, no guarantee that you've actually handled every case."

... So what? From what I can tell that's all anyone has asked for in the context of something to just return nil/error up the call stack.

2 comments

Exactly. I don't like that many people say "It's not perfect so it's useless.". I don't want to write or read the `if err != nil` statement over and over again. It is messy. It is tiresome. It could be solved by syntactic sugar.
I actually think it defeats the Go teams stated purpose. It may technically be "more explicit" but it causes too problems. First someone is far more likely to just use the old value, _ trick bedside the current usage is just so annoying. Secondly, it conditions a lot of devs to just skim over the if check, because half the damn time it's just bs.

A little syntax sugar that won't break backwards compatibly and makes the intent of the code clearer is a win-win. I've never seen a really reasonable response from the Go team on why they don't want to do it.

llm garbage
agreed, the author should be upfront that it was written by an LLM
The llm detector in my brain went off too
Every paragraph in the article is exactly what LLM produces