error types/strings and errors.Is

[Kevin Chadwick]

Are there any thoughts on how to handle error types. Will the user create custom
error types from strings for use with errors.Is like for their own code or are
some error strings in the stdlib likely to change. In which case an "import
errors/types" managed by the stdlib might make sense?

proposal: Go 2 error values

https://github.com/golang/go/issues/29934#issuecomment-546896170

[Ian Lance Taylor]

I don't think there is any one solution that will be used in all
cases. Where the standard library can reasonably provide a shared
error type, it should, as it already does for types like os.PathError
and os.SyscallError. For a user package, whether it returns a
specific error type is part of that package's API. Often there is no
need for special error types for a user package. Where there is a
need, the error types should be documented like any other part of the
API.

Ian

[Kevin Chadwick]

On 2020-09-28 23:28, Ian Lance Taylor wrote:
> I don't think there is any one solution that will be used in all
> cases. Where the standard library can reasonably provide a shared
> error type, it should, as it already does for types like os.PathError
> and os.SyscallError. For a user package, whether it returns a
> specific error type is part of that package's API. Often there is no
> need for special error types for a user package. Where there is a
> need, the error types should be documented like any other part of the
> API

Is ENETUNREACH - "network is unreachable" typed anywhere? I assume string
matching on these is part of the Go 1 promise?

[Axel Wagner]

On Tue, Sep 29, 2020 at 5:37 PM Kevin Chadwick <m8il...@gmail.com> wrote:

Is ENETUNREACH - "network is unreachable" typed anywhere? I assume string
matching on these is part of the Go 1 promise?

I hope not. If you want to handle a specific error, what you should do is file an issue to expose that error as a type (and thus make it part of the API of the package), not to match strings - precisely *because* they aren't part of the stable API, if they are not exposed, so shouldn't be relied on.

For your specific case, have you tried `errors.Is(err, syscall.Errno(syscall.ENETUNREACH))`?

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1f29dfd6-2f41-ac84-6ee8-c9ff0d4bf917%40gmail.com.

[Kevin Chadwick]

On 2020-09-29 18:38, Axel Wagner wrote:
> I hope not. If you want to handle a specific error, what you should do is file
> an issue to expose that error as a type (and thus make it part of the API of the
> package), not to match strings - precisely *because* they aren't part of the
> stable API, if they are not exposed, so shouldn't be relied on.
>

OK. I expected not but thought they were unlikely to change atleast.

> For your specific case, have you tried `errors.Is(err,
> syscall.Errno(syscall.ENETUNREACH))`?

That works, Thank You

I feel like a few of these should probably be exposed in the net package?
Perhaps they haven't because different systems return different ones in
different circumstances, but I hope Posix means that isn't the case.

[Axel Wagner]

On Wed, Sep 30, 2020 at 10:51 AM Kevin Chadwick <m8il...@gmail.com> wrote:

I feel like a few of these should probably be exposed in the net package?

Some are. The point behind the new errors package is that the rest don't need to :)

Perhaps they haven't because different systems return different ones in
different circumstances, but I hope Posix means that isn't the case.

Not all platforms Go runs on are Posix. Plan 9 comes to mind, but also webassembly and embedded devices. 

 

I think in general, trying to replicate these underlying errors is not a good idea. They are very platform-dependent and how to handle them and which errors are "interesting" classes is really application-dependent (for example, I have never introspected an error returned by the net package, so far). The current approach of passing them through mostly untouched still allows the application to make any decision it wants based on them - and that's where the necessary information is anyway.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/091726ef-29c6-31f1-f128-b2a15ebea26a%40gmail.com.

[Jesper Louis Andersen]

On Wed, Sep 30, 2020 at 11:27 AM 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:

Perhaps they haven't because different systems return different ones in
different circumstances, but I hope Posix means that isn't the case.

Not all platforms Go runs on are Posix. Plan 9 comes to mind, but also webassembly and embedded devices. 

 

And even given Posix, you might have small variance in exact interpretation of certain error codes or constants, so it tends to be a good thing to make sure your operating system interprets them as you expect. In addition, many modern APIs live outside the umbrella of Posix, making things even more fluctuating in what you can expect. As a general rule, I tend to go with Alex suggestion: pack them away until they are needed and only use them with surgical precision.

[Kevin Chadwick]

> The current approach of passing them through mostly untouched still allows the
> application to make any decision it wants based on them - and that's where the
> necessary information is anyway.

I like the approach with multi return far more than Darts try, catch etc. My
first thought was that perhaps they shouldn't need a grep to find, but that is
of course easier said than done, with so many builds.

>> And even given Posix, you might have small variance in exact interpretation
>> of certain error codes or constants, so it tends to be a good thing to make
>> sure your operating system interprets them as you expect. In addition, many
>> modern APIs live outside the umbrella of Posix, making things even more
>> fluctuating in what you can expect. As a general rule, I tend to go with Alex
>> suggestion: pack them away until they are needed and only use them with
>> surgical precision.

I don't actually need them logically, though I did a little when using TLS. The
errors.Is is mainly to give a user a more friendly rectification message and the
actual log message if a more information button, is clicked.

I'm OK with testing and grepping for them though, actually. Especially with the
stability that syscall.Errno brings.

Regards, kc