proposal query EOF/unexpectedEOF

[Dan Kortschak]

In some code I was recently reviewing I found a need-ish to be able to
consider io.ErrUnexpectedEOF and io.EOF as similar or the same error
depending on context. With the existence of error wrapping now, it
seemed to me that this could be done by having io.EOF wrapped in
another error.

I've tried this and the go project passes all tests, but I could
imagine that there are some users of io.ErrUnexpectedEOF that could
possibly break (I can't really see how).

Two questions:

1. Is this something that would be worth proposing?
2. If 1. is yes, should it go through the Go2 proposal process.

For completeness, the following is the change I made:

```
// ErrUnexpectedEOF means that EOF was encountered in the
// middle of reading a fixed-size block or data structure.
var ErrUnexpectedEOF = unexpectedEOF

var unexpectedEOF error = unexpectedErr{EOF}

type unexpectedErr struct{ err error }

func (e unexpectedErr) Error() string {
return "unexpected " + e.err.Error()
}

func (e unexpectedErr) Unwap() error {
return e.err
}
```

I am aware that the logic for using this can be replaced by a switch/if
statements, but the use of errors.Is/errors.As is nicer.

thanks
Dan

[peterGo]

Dan,

Will this code continue to work?

Playground: https://play.golang.org/p/R1mdgiU4S1Q

Peter

[Dan Kortschak]

Yes. The two errors are distinct, just that one wraps the other.

Dan

~ $ go run pgt.go
1024 bytes read
1024 bytes read
512 bytes read

[Dan Kortschak]

But, did yo mean this?

https://play.golang.org/p/1y7eKm0y2Hc

Also yes.

~ $ go run pgt.go
1024 bytes read
1024 bytes read
512 bytes read

unexpected EOF

[Russ Cox]

Hi Dan,

io.EOF and io.ErrUnexpectedEOF are very different errors.

The difference is that io.EOF is a "clean EOF" at a proper

I/O boundary (from the level of abstraction of the reader that

returned it), while io.ErrUnexpectedEOF is a mid-record EOF.

The former is an ordinary thing to expect and the latter usually

indicates some kind of data corruption. It would be a problem

for the standard library to not allow using errors.Is to distinguish

these two. (And we want to preserve the rule that errors.Is is

a drop-in unwrapping replacement for ==. We can't make it a

condition of adopting errors.Is that these two errors are now 

blurred together.)

I'm not surprised that nothing breaks in the main tree if

you arrange to blur the two since there is not much code in the

main tree that:

 - unwraps or distinguishes errors at all

 - uses errors.Is

 - runs in contexts where ErrUnexpectedEOF happens

But I would expect subtle problems to crop up in higher-level

applications. Merging these two errors is not something we

should do as a default.

Best,

Russ

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/c6bb9c585a6988f7a6f9d10e673fc60e36c362e4.camel%40kortschak.io.

[Dan Kortschak]

Hi Russ,

Thanks for the clear explanation.

regards
Dan