Internal errors are one of my pet peeves about the core go libs, as you
say they are inconsistent and you end up doing all sorts of string
checks which are not only hackey but are very fragile too. We had a
break in our code due to just this when updating to 1.8.
There are very few reason why errors should be private in my mind
especially simple errors.New(...) ones.
I would personally love to see this fixed.
Regards
Steve
On 24/02/2017 10:28, [email protected] wrote:
I'm currently upgrading an application to Go 1.8 (thanks for the
compile time speed boost, by the way).
I'm falling over a lot of issues with URL parsing now blowing up on
RFC3986 compliance issues
(see https://github.com/golang/go/blob/ea5529de155cfd3f2c31698344b1ca001e0f8819/src/net/url/url.go#L517)
and something occured to me.
In net/http for example the vars ErrBodyNotAllowed, ErrHijacked,
ErrContentLength etc are provided at the top level, whereas in the
changes to the URL package (linked above) simply use errors.New() inline.
It strikes me that the stdlib is very inconsistent in this regard, and
it makes my job in checking for valid/invalid URLs more difficult as
I'm now doing sub string matching on err.Error() which leaves a bad
taste in my mouth.
What're people's thoughts, would it be worth my investing time to
prepare a patchset for 1.9 to normalize this, so that all errors in
the stdlib are handled the same way that net/http handles them, as top
level package vars?
Cheers, Lee
--
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 [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
