[richbell]

> I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages.

This implies that the only people who dislike Go's error handling are newbies that "don't get it".

Go's error handling is objectively bad for two reasons:

1. You are never forced to check or handle errors. It's easy to accidentally miss an `if err != nil` check, I've seen sages and newbies alike make this mistake.

> Errors in Go are right there, in your face, and undeniable that the operation you are doing can be faulty somehow.

2. Repeating `if err != nil` ad nauseam is not handling errors. Knowing the operation can be faulty somehow is a good way of putting it, because in most cases it's difficult — if not impossible — to figure out what specific failures may occur. This is exacerbated by the historical reliance on strings. e.g., Is it a simple issue that can be easily recovered? Is it a fatal error?

[aiono]

> You are never forced to check or handle errors. It's easy to accidentally miss an `if err != nil` check, I've seen sages and newbies alike make this mistake.

While I also don't like Go's error handling approach I thought Go compiler gives an error if a variable is unused, in this case `err`. Is this not the case?

[richbell]

> While I also don't like Go's error handling approach I thought Go compiler gives an error if a variable is unused, in this case `err`. Is this not the case?

This isn't foolproof. If you're calling multiple methods and reusing `err` it won't give an error because it's technically not unused.

[aiono]

I didn't know that, this seems like a big foot gun tbh

[teeray]

> You are never forced to check errors…

There are linters that do, and I am of the opinion they should be added to `go vet`.

> Knowing the operation can be faulty somehow is a good way of putting it, because in most cases it's difficult — if not impossible

Guru was once able to tell you exactly what errors could be generated from any given err. Now that the world is LSP, we have lost this superpower.

[pjmlp]

Traditionally linters are workarounds for features that should be in the language.

Instead we pack best practices in an external tool.