5 ms·

Java's exceptions are also visible in the signature, and harder to ignore. I actually like Go's solution better, because it's verbose, because the fact that I

Java's exceptions are also visible in the signature, and harder to ignore. I actually like Go's solution better, because it's verbose, because the fact that I pay the cost of "if err != nil" every effin time, I'm more likely to consider what happens. Because if the flow is not linear with those, I'm more likely to break out a function and give it a name.

daveliepmann 2y ago
The "error maps" approach from the article doesn't have Go's compiler enforcement, but shares many attributes including the "being explicit about how to handle an error" aspect you mention.
jiehong 2y ago
Go error handling is nice, but not super mandatory. I’ve seen functions only returning an error being called without the error being assigned to anything and never checked. The compiler does not care, only go ci lint would block that. I’ve also seen a function returning a value and and error, and the error being mapped to _ on the caller side. Compiler and linter are fine with that (and sometimes it’s mandatory with some weird libraries). Lastly, a nitpick: should functions return (value, error, or (error, value)? The former is a convention, but the latter happens sometimes in some libraries.
- daveliepmann 2y ago
  >should functions return (value, error), or (error, value)? a benefit of using maps with error keys :D semantic rather than positional destructuring. also avoids that needlessly obfuscatory Left and Right terminology for Either monads
- ncruces 2y ago
  > I’ve also seen a function returning a value and and error, and the error being mapped to _ on the caller side. Compiler and linter are fine with that (and sometimes it’s mandatory with some weird libraries). Yes, that's the way to explicitly ignore the error. Ignoring the result, instead of attributing to the blank identifier _ , is bad form (unless you're doing something like defer a Close).

daveliepmann 2y ago

The "error maps" approach from the article doesn't have Go's compiler enforcement, but shares many attributes including the "being explicit about how to handle an error" aspect you mention.

jiehong 2y ago

Go error handling is nice, but not super mandatory. I’ve seen functions only returning an error being called without the error being assigned to anything and never checked. The compiler does not care, only go ci lint would block that. I’ve also seen a function returning a value and and error, and the error being mapped to _ on the caller side. Compiler and linter are fine with that (and sometimes it’s mandatory with some weird libraries). Lastly, a nitpick: should functions return (value, error, or (error, value)? The former is a convention, but the latter happens sometimes in some libraries.

daveliepmann 2y ago
>should functions return (value, error), or (error, value)? a benefit of using maps with error keys :D semantic rather than positional destructuring. also avoids that needlessly obfuscatory Left and Right terminology for Either monads
ncruces 2y ago
> I’ve also seen a function returning a value and and error, and the error being mapped to _ on the caller side. Compiler and linter are fine with that (and sometimes it’s mandatory with some weird libraries). Yes, that's the way to explicitly ignore the error. Ignoring the result, instead of attributing to the blank identifier _ , is bad form (unless you're doing something like defer a Close).