Non-CloseError, non-sentinel error on EOF

[cameronelliott]

First, before I launch into my issue, let me say, thanks for writing nhooyr/websocket, I see some things I really love, like the support for contexts on the reads and writes, and lots of other great decisions!

Anyway...

I got a stack trace as included below, where the bold text of the error is from nhooyr/websocket, and the non-bold part preceding the bold is from my code.
Basically what happened, is an EOF occurred on a read, which is nothing unusual in production.

But, what I am surprised about, is that a non-sentinel type error was returned for the EOF on read.
(A type of 'error', rather than a chain containing 'CloseError')
What are sentinel errors

I kind of was hoping to get an error chain where 'CloseError' was included on any EOF conditions.

(like maybe this EOF could be converted to CloseError.StatusGoingAway or something similar.)

So, I am wondering if you think getting to the point where all EOFs possible return a sentinel-error
is a good idea, or not really?

Thanks,
Cameron

F1013 20:16:12.719740 1448 main.go:234] err or read() or write() 192.168.86.1:39038: failed to get reader: failed to read frame header: EOF
goroutine 44 [running]:
github.com/golang/glog.stacks(0xc00007b500, 0xc0003ce0a0, 0x8f, 0x9d)
/home/c/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:769 +0xb9
github.com/golang/glog.(*loggingT).output(0xb60640, 0xc000000003, 0xc000142620, 0xb02a1a, 0x7, 0xea, 0x0)
/home/c/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:720 +0x39a
github.com/golang/glog.(*loggingT).printf(0xb60640, 0x3, 0x8a171e, 0x1f, 0xc00057f9d8, 0x2, 0x2)
/home/c/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:655 +0x153
github.com/golang/glog.Fatalf(...)
/home/c/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:1148
main.handleSource(0x920160, 0xc0000c4380, 0xc0000b6900)
/home/c/back2back/main.go:234 +0x58c
net/http.HandlerFunc.ServeHTTP(0x8b6448, 0x920160, 0xc0000c4380, 0xc0000b6900)
/usr/local/go/src/net/http/server.go:2042 +0x44
github.com/gorilla/mux.(*Router).ServeHTTP(0xc0001580c0, 0x920160, 0xc0000c4380, 0xc0000b6700)
/home/c/go/pkg/mod/github.com/gorilla/mux@v1.8.0/mux.go:210 +0xd3
net/http.serverHandler.ServeHTTP(0xc000176380, 0x920160, 0xc0000c4380, 0xc0000b6700)
/usr/local/go/src/net/http/server.go:2843 +0xa3
net/http.(*conn).serve(0xc0001d0320, 0x920d60, 0xc000098f00)
/usr/local/go/src/net/http/server.go:1925 +0x8ad
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2969 +0x36c
exit status 255

[nhooyr]

Hi @cameronelliott!

First, thanks for the kind words!

So according to the WebSocket spec, we shouldn't be doing any such conversion. Instead, we can return StatusAbnormalClosure as browsers do when a connection randomly terminates but I decided it'd be better to return the full Go error but now I'm not entirely sure. I can see how this is confusing.

I'll keep this issue open and think on it for the next release.

[cameronelliott]

UPDATE:
I have been going through a lot of machinations learning how 1.13 and later
error handling works.

When posting the below update, I did not realize that %w is effectively the
same as the errors.Wrap() function proposed by Dave Cheney.

Now that I understand the %w specifier, I understand that errors are getting
wrapped just like the errors.Wrap() function did in Dave's original library.

Thanks for your patience!!

Really appreciate nhoory/websocket.

All the following comments are based upon my misguided understanding of how fmt.Errorf works

---

I am not sure why RSC proposed using fmt.Errorf() to wrap errors,
in errd.Wrap
rather than errors.Wrap(), but it seems problematic from
the perspective of easily identifying io.EOF errors,
as the usage of fmt.Errorf() doesn't use an error chain, and
thus requires receivers of errors to parse strings rather
than use if errors.Is(err, io.EOF) { to detect closed
socket conditions.

If we were to use errors.Wrap() rather than fmt.Errorf(),
it may simplify io.EOF handling, and thus creating
robust websocket servers.

Are you open to discussing the pros and cons of this?

P.S.
This article by the author of pkg/errors, explains the
downsides of using fmt.Errorf() vs errors.Wrap()
Dave Cheney Talk/Post Don’t just check errors, handle them gracefully 2016

Even something as well meaning as using fmt.Errorf to add some context to the error will defeat the caller’s equality test. Instead the caller will be forced to look at the output of the error‘s Error method to see if it matches a specific string.

[nhooyr]

Np, glad you figured things out!

I was just visiting family the last few days so didn't have time to respond.