4 ms·

It errors because the type of `err` is `error`, not *formatError. That's why you are supposed to return the error interface, instead of a concrete type. The va

It errors because the type of `err` is `error`, not *formatError. That's why you are supposed to return the error interface, instead of a concrete type. The value ends up being a non-nil interface value that holds nil. To avoid encountering this issue, return `error`, not something else. https://play.golang.org/p/jZ5Fa24bbUz https://play.golang.org/p/jZ5Fa24bbUz

chrsm 8y ago
The real issue here is that it is not immediately obvious that this is actually an interface - one expects the second `err` to be *FormatError due to the signature - it happens to implement the error interface so it goes unnoticed. Shadowing in a different scope allows it to work properly as well. I admit that I've never actually run in to this issue in practice as I generally return custom errors as `error`, but I can see why it would confuse someone.
- echlebek 8y ago
  Totes.
- deleted 8y ago
  [deleted]
hombre_fatal 8y ago
> To avoid encountering this issue, return `error`, not something else. But best practice is to return concrete types. Also, `err` is just an example in this minimal snippet. It can happen with any variable. Here's a similar snippet: https://play.golang.org/p/WKPey_PL_ht https://play.golang.org/p/WKPey_PL_ht -- Looks impossible to crash. :P Spoiler: it's a boxed null, not a null.
- thegeekpirate 8y ago
  > But best practice is to return concrete types. You're taking this as an absolute when you shouldn't be. There's plenty of places in the standard library that don't follow this "rule".
  - deleted 8y ago
    [deleted]
- chrsm 8y ago
  Best practice is to return concrete types for everything, but error is one of those "special" cases that people tend to return an `error` for, IME. You can always unwrap it via type assertion, however ugly that may be.
- skj 8y ago
  > But best practice is to return concrete types. Except for errors. Use the `error` interface.

chrsm 8y ago

The real issue here is that it is not immediately obvious that this is actually an interface - one expects the second `err` to be *FormatError due to the signature - it happens to implement the error interface so it goes unnoticed. Shadowing in a different scope allows it to work properly as well. I admit that I've never actually run in to this issue in practice as I generally return custom errors as `error`, but I can see why it would confuse someone.

echlebek 8y ago
Totes.
deleted 8y ago
[deleted]

hombre_fatal 8y ago

> To avoid encountering this issue, return `error`, not something else. But best practice is to return concrete types. Also, `err` is just an example in this minimal snippet. It can happen with any variable. Here's a similar snippet: https://play.golang.org/p/WKPey_PL_ht https://play.golang.org/p/WKPey_PL_ht -- Looks impossible to crash. :P Spoiler: it's a boxed null, not a null.

thegeekpirate 8y ago
> But best practice is to return concrete types. You're taking this as an absolute when you shouldn't be. There's plenty of places in the standard library that don't follow this "rule".
- deleted 8y ago
  [deleted]
chrsm 8y ago
Best practice is to return concrete types for everything, but error is one of those "special" cases that people tend to return an `error` for, IME. You can always unwrap it via type assertion, however ugly that may be.
skj 8y ago
> But best practice is to return concrete types. Except for errors. Use the `error` interface.