5 ms·

Many Rust programmers despise Go's "if err != nil" pattern, but that pattern actually forces you to think about errors and "design" them to give meaningful mess

Many Rust programmers despise Go's "if err != nil" pattern, but that pattern actually forces you to think about errors and "design" them to give meaningful messages, either by wrapping them (if the underlying error is expected to provide userful information), or by creating a one from scratch. It may be easier to just add the "?" operator everywhere (and we are lazy and will mostly do what is easier), but it often leads to problem explained in the article.

jayknight 9mo ago
>that pattern actually forces you to think about errors and "design" them to give meaningful messages Doesn't Rust's Result type(s) force you to do the same? Sure, you can pass them on with the ? operator, but it's still a choice you have to make.
alembic_fumes 9mo ago
Hard disagree. Most of the Go code that I've ever worked with has been littered with one or another variant of the following: value, err := doFallibleOperation() if err != nil { return nil, fmt.Errorf("fallible operation failed - %w", err) } That error construct exclusively works for the poor human who has to debug the system, looking at its logs. No call stacks and, crucially, no automatic handling. At least with Rust's enums it is possible to make errors automatically actionable. If one skips that part and opts for anyhow because it's too much work, that's really a user problem. I like the author's idea of "designing" errors by exposing their actionability in the interface a lot. I'm not overall sold on whether that should be the primary categorization, but at least including a docstring to each enum variant about what can be done about the matter sounds like a nice way to improve most code a little bit.
- Fizzadar 9mo ago
  As a primarily Go dev - 100% agree. The endless check and wrap error results in long chains of messages you have to grep for to understand the call stack. For what benefit? Might as well just panic and recover/log the stack in many cases.
  - formerly_proven 9mo ago
    Artisanal callstacks
  - deleted 9mo ago
    [deleted]
  - morshu9001 9mo ago
    The error handling is by far my least favorite aspect of Go. It's tedious and dangerous. It should either be like Rust or like JS, there isn't a good third option.
    - tcfhgj 9mo ago
      what about checked exceptions (Java)?
      - morshu9001 9mo ago
        Isn't JS the same? But seems like people tend to make a lot of exception types in Java with inheritance, which I think is overkill. Typically I'll only have a couple of exception types that my own code throws, like user error vs system error. If I want more detail than that, it goes into the exception payload rather than defining many different types of exceptions.
- bheadmaster 9mo ago
  > If one skips that part and opts for anyhow because it's too much work, that's really a user problem. If a language makes this more convenient than doing it right, one could argue that the language design is at fault.
- Thaxll 9mo ago
  In many code base you have custom errors that implement the error interface ( for http code and the like ), it's very common.
akdor1154 9mo ago
I think that was the intent of Go's design, but in practise i think it normally devolves into an overly verbose '?' with a poorly typed Result<_, String>. As a Go dev, I'm looking at this article with great interest. I would very much like to apply this approach to Go as well, I think the author has got a very strong design there.
tison 9mo ago
FWIW, here is a general discussion about error handling in Rust and my comment to compare it with Go's/Java's flavor: https://github.com/apache/datasketches-rust/issues/27#issuecomment-3666011425 https://github.com/apache/datasketches-rust/issues/27#issuec... That said, I can live with "if err != nil", but every type has a zero value is quite a headache to handle: you would fight with nil, typed nil, and zero value. For example, you need something like: type NullString struct { String string Valid bool // Valid is true if String is not NULL } .. to handle a nullable value while `Valid = false && String = something` is by defined invalid but .. quite hard to explain. (Go has no sum type in this aspect)

jayknight 9mo ago

>that pattern actually forces you to think about errors and "design" them to give meaningful messages Doesn't Rust's Result type(s) force you to do the same? Sure, you can pass them on with the ? operator, but it's still a choice you have to make.

alembic_fumes 9mo ago

Hard disagree. Most of the Go code that I've ever worked with has been littered with one or another variant of the following: value, err := doFallibleOperation() if err != nil { return nil, fmt.Errorf("fallible operation failed - %w", err) } That error construct exclusively works for the poor human who has to debug the system, looking at its logs. No call stacks and, crucially, no automatic handling. At least with Rust's enums it is possible to make errors automatically actionable. If one skips that part and opts for anyhow because it's too much work, that's really a user problem. I like the author's idea of "designing" errors by exposing their actionability in the interface a lot. I'm not overall sold on whether that should be the primary categorization, but at least including a docstring to each enum variant about what can be done about the matter sounds like a nice way to improve most code a little bit.

Fizzadar 9mo ago
As a primarily Go dev - 100% agree. The endless check and wrap error results in long chains of messages you have to grep for to understand the call stack. For what benefit? Might as well just panic and recover/log the stack in many cases.
- formerly_proven 9mo ago
  Artisanal callstacks
- deleted 9mo ago
  [deleted]
- morshu9001 9mo ago
  The error handling is by far my least favorite aspect of Go. It's tedious and dangerous. It should either be like Rust or like JS, there isn't a good third option.
  - tcfhgj 9mo ago
    what about checked exceptions (Java)?
    - morshu9001 9mo ago
      Isn't JS the same? But seems like people tend to make a lot of exception types in Java with inheritance, which I think is overkill. Typically I'll only have a couple of exception types that my own code throws, like user error vs system error. If I want more detail than that, it goes into the exception payload rather than defining many different types of exceptions.
bheadmaster 9mo ago
> If one skips that part and opts for anyhow because it's too much work, that's really a user problem. If a language makes this more convenient than doing it right, one could argue that the language design is at fault.
Thaxll 9mo ago
In many code base you have custom errors that implement the error interface ( for http code and the like ), it's very common.

akdor1154 9mo ago

I think that was the intent of Go's design, but in practise i think it normally devolves into an overly verbose '?' with a poorly typed Result<_, String>. As a Go dev, I'm looking at this article with great interest. I would very much like to apply this approach to Go as well, I think the author has got a very strong design there.

tison 9mo ago

FWIW, here is a general discussion about error handling in Rust and my comment to compare it with Go's/Java's flavor: https://github.com/apache/datasketches-rust/issues/27#issuecomment-3666011425 https://github.com/apache/datasketches-rust/issues/27#issuec... That said, I can live with "if err != nil", but every type has a zero value is quite a headache to handle: you would fight with nil, typed nil, and zero value. For example, you need something like: type NullString struct { String string Valid bool // Valid is true if String is not NULL } .. to handle a nullable value while `Valid = false && String = something` is by defined invalid but .. quite hard to explain. (Go has no sum type in this aspect)