On Fri, 24 Feb 2017 02:28:39 -0800 (PST)
lee.hamb...@gmail.com 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.

In this particular case, isn't it subsequently wrapped in a custom
error type in an outer function [2]?

That is, your client code will actually get an error value of type
net/url.Error with its Op field being set to "parse".
I reckon your code relies on coercing these types into strings via
their Error() method and then checking the string rep.
If I'm correct, a better approach is to type-assert the error returned
to see if it's of type net/url.Error, and then checking whether its
Op field equals "parse".

> 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?

Well, it's not me who decides but this looks to me as a "where should
be draw the line?" kind of situation: as it appears, the "url" package
already tells its clients which "kind" of error has happened ("parse"
in your case), and this pretty much matches, say, what the "os" package
does for errors related to operations on files.  Maybe an additional
field in net/url.Error which would contain some errno-like value of a
set exported from the package would be OK?

2. 
https://github.com/golang/go/blob/ea5529de155cfd3f2c31698344b1ca001e0f8819/src/net/url/url.go#L460

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to