Hacker News Reader

Comment by MobiusHorizons | Hacker News Reader

My guess is that the author hasn’t fully frocked how go interfaces work yet. Go errors implement the error interface, but that just makes them interoperable, it doesn’t mean that’s all they are.

View on HN

Correct me if I am wrong, but does it not mean that they are type-erased though? The whole point of returning an interface is to perform type-erasure.

If I have

    struct S { X int }
    func (s *S) Error() string { ... }

but I return it as an error:

    func DoStuff() error

Then all the caller gets is an error interface. Without downcasting (`.(T)`/`errors.As`), you can only compare it to other instances (if the library author provided them) or see the string representation.

Yes, that's correct. The interface limits what guarantees the caller has about the type without runtime introspection. I don't think that really makes it any harder to handle expected error conditions though, since type assertions return a boolean. eg:

    if myErr, ok := err.(MyError); ok {
        // handle MyError case
    }
    ...

But you should always expect that there could be errors you don't expect to exhaustively handle with special logic.

Reply on news.ycombinator.com