Improve CloseError API

[nhooyr]

I think the current API is a little obnoxious since it forces you to use xerrors.As to get the close error code which is very annoying.

Also people forget to use xerrors.As, see https://github.com/sumorf/deribit-api/blob/6b581052e02d0808bed0bdc7a04f3dc4582e70d3/stream.go#L30

@sumorf

I don't like the ceremony involved with xerrors.As so I'd like to provide some sort of convenience API to get the error code.

[nhooyr]

Any thoughts @coadler @ammario?

[nhooyr]

Noticed another package with this problem.

https://github.com/andersfylling/disgord/blob/57dbd4d0711898c0601bfaa714f0c26e988a6217/websocket/websocket_nhooyr.go#L65

@andersfylling

[coadler]

I don't mind using xerrors.As to get extra information. Since it's moving to std errors in 1.13 I think that approach might start being more common, though I wouldn't see an issue with adding a helper function

[andersfylling]

I would prefer a helper method. At least until 1.13 is released and a std approach exists.

Edit: right now I've just imported xerrors to handle it properly. You could just show how to properly handle your error types as now many are used to xerrors yet.

[nhooyr]

Yea I suppose the simplest approach for now is to just add an example of accessing CloseError to the README.

What do you guys think of unexporting the CloseError struct all together and exporting:

func CloseError(err error) (code StatusCode, reason string, ok bool)

Would be pretty much impossible to misuse and consumers would never have to think about xerrors.As and how to grab the error properly.

[nhooyr]

imo its better if xerrors.As is an implementation detail and not something consumers think about.

[andersfylling]

I would say:
If you want to keep go 1.12 support, then yes.
If you want to use go1.13 then just stick with the .As method, as that will have std support when 1.13 is released.

A compromise would be to keep the error struct exported and provide that helper method (marked deprecated). Then people can choose.

[nhooyr]

@jba what would you recommend as the public API library author's go for? Is it better to expose the error structure and require consumers use xerrors.As or provide a helper?

[ammario]

It seems like Go intends on everyone using xerrors.As, right? I think a helper method for each error type is excessive duplication.

[nhooyr]

Yes, I think you're right. I've added an example which should help with the confusion.