On Mon, Sep 28, 2020 at 3:46 AM Kevin Chadwick <m8il1i...@gmail.com> wrote: > > 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
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 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUHw0uLfDwDYzv8E7%3DCKhjz%2BX_sB8r0UmWg%3DSTaNj6wiw%40mail.gmail.com.
