error processing (again!)

[Denis Cheremisov]

How it looks like

Just a simple construct which doesn't take any new word in its simplest form

configFile := os.Open(arg.config) else err {
    return fmt.Errorf("open config file: %w", err)
}

could be

func someCall() (int, string, error) {
    // ...
}

// ...

x, y := someCall() else err {
    // ...
}

Extended

An extended form would require a new reserved word (`emit`)

input := os.Open(arg.input) else err {
    slog.Warn("failed to open input file", "input-name", arg.input, "err", err)
    emit os.Stdin
}

Not just for errors

var counts map[string]int
// ...
count := counts[key] else {
    slog.Warn("missing counter in the blah-blah-blah", "missing-counter", key)
    continue
}


Pros:

• 100% explicit and promote the right way of error processing.
• Just in line with the current philosophy of happy path in priority and the error path as an important yet step child. More in line actually…
• Uniform way to process results + error and just error. Unlike the current

  
  file, err := os.Open(name)
  if err != nil {
      return fmt.Errorf("open config file: %w", err)
  }
  
  vs
  

  if err := os.Rename(...); err != nil { ... }
  

• As you see, this is ready to use deconstruction for Result[T] and Option[T] types, not just a syntactic sugar for `(…, error)` or `(…, bool)`. Meaning, it is 100% future proof.
  

Cons:

• Frankly, I don't see any. Besides a holy laziness of course.
  

[Ian Lance Taylor]

Seems pretty similar to https://github.com/golang/go/issues/71203.

On this topic, though, note https://go.dev/blog/error-syntax.

Ian