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.

> 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 -- Looks impossible to crash. :P

Spoiler: it's a boxed null, not a null.

> but having nullable types is a real mistake to me.

Nullable types by themselves are fine, the language and the compiler just needs to make handling “is X null?” work the same way as option types do - or better yet: languages were a variable is only in scope if it is not null.