Hacker News Reader

> e.g. net.OpError

I have my own complain against Rust's error handlings, but I can't bring myself to praise what Go has been doing.

One problem with the error interface is that you can't know exactly which error type will be returned, and the Go authors may add new error types form time to time. `net.OpError` itself is a great example for that, which is a newer type than net.Error.

This style of error signalling is best used when the error handling is binary, either "No error, continue" or "Errored out, abort", but not branched out path like "If encountered error A, do this. If encountered error B, do that. Otherwise, abort".

Rust's error handling encourages such branched out handlings by default, but if you want to so the same in Go, there will be a nightmarish manual type discovery and tracking operation waiting for you.

So for me, I rather use a dedicated signal code to tell which error branch I should do next rather than relying on the error, i.e:

    if next, err := func(); err != nil { // If errored, abort it
        return err
    } else if next == condition1 {
        return op1()
    } else if next == condition2 {
        return op2()
    } else {
        panic("unsupported condition")
    }

View on HN

> This style of error signalling is best used when the error handling is binary, > either "No error, continue" or "Errored out, abort", but not branched > out path like "If encountered error A, do this. If encountered error B, > do that. Otherwise, abort".

type ErrFoo struct { // fields // } type ErrBar struct { // fields // } if var errFoo *ErrFoo; errors.As(err, &errFoo) { // handle ErrFoo } if var errBar *ErrBar; errors.As(err, &errBar) { // handle ErrBar }

// top-level, e.g. exported by package type MyErrorStruct struct { Op string Path string } var ( OpFoo string = "foo" OpBar string = "bar" ) var opErr *MyErrorStruct if errors.As(err, &opErr) { if opErr.Op = OpFoo { // handle OpFoo at path opErr.Path } if opErr.Op = OpBar { // handle OpBar at path opErr.Path } }

// top-level, e.g. exported by package var ErrFoo = errors.New("foo") var ErrBar = errors.New("bar") if errors.Is(err, ErrFoo) { // handle ErrFoo } if errors.Is(err, ErrBar) { // handle ErrBar }

match File::open("filename.txt") { Ok(file) => {} Err(io_err) => match io_err.kind() { ErrorKind::IsADirectory => {} // Notice how not every error type is handled }, }

> Since the some function may just return an error interface, there's > no way for the end user to know you've added that error type. From > their prospective, everything is unchanged, and still compiles just fine.