<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>politician</author><text>Also note that the library checks for `: %w` at the end of the format string to enable this wrapping feature.  If you use &amp;quot;%w&amp;quot; anywhere else in the format string it won&amp;#x27;t work.&lt;p&gt;Yuck.</text><parent_chain><item><author>nickcw</author><text>This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney&amp;#x27;s errors package (which I love) into the standard library: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;pkg&amp;#x2F;errors&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;pkg&amp;#x2F;errors&lt;/a&gt;&lt;p&gt;Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit.&lt;p&gt;I don&amp;#x27;t like the `fmt.Errorf(&amp;quot;more description: %w&amp;quot;, err)` though for several reasons.&lt;p&gt;Firstly it is a lot more opaque than Dave Cheney&amp;#x27;s original mechanism errors.Wrap(err, &amp;quot;more description&amp;quot;).   You&amp;#x27;ve got to check the format string for a `%w` to see if it is wrapping an error or not.&lt;p&gt;Secondly why is this really important functionality in `fmt` and not in `error`?&lt;p&gt;And finally we&amp;#x27;ve been encouraged to write `fmt.Errorf(&amp;quot;more description: %v&amp;quot;, err)` (note `%v` not `%w`), so I think there will be a lot of unwrapped errors.&lt;p&gt;...&lt;p&gt;I&amp;#x27;m not sure enough has been thought about the backwards incompatibility. With rclone I try to maintain compatibility with the current go release and a few previous ones so that rclone can remain running with distro go versions and gccgo both of which are a bit behind.  For something as common as error handling this will cause lots of libraries to suddenly be no longer usable with anything less than go1.13.&lt;p&gt;IMHO I think this would be better staying as a non standard library package for the time being while more kinks are worked out.</text></item></parent_chain></comment><story><title>Go 1.13: xerrors</title><url>https://crawshaw.io/blog/xerrors</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>TheSwordsman</author><text>+1 on all of this. I really prefer that &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;pkg&amp;#x2F;errors&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;pkg&amp;#x2F;errors&lt;/a&gt; is outside of the standard library so I don&amp;#x27;t need to use the fmt.Errorf abomination.</text><parent_chain><item><author>nickcw</author><text>This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney&amp;#x27;s errors package (which I love) into the standard library: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;pkg&amp;#x2F;errors&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;pkg&amp;#x2F;errors&lt;/a&gt;&lt;p&gt;Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit.&lt;p&gt;I don&amp;#x27;t like the `fmt.Errorf(&amp;quot;more description: %w&amp;quot;, err)` though for several reasons.&lt;p&gt;Firstly it is a lot more opaque than Dave Cheney&amp;#x27;s original mechanism errors.Wrap(err, &amp;quot;more description&amp;quot;).   You&amp;#x27;ve got to check the format string for a `%w` to see if it is wrapping an error or not.&lt;p&gt;Secondly why is this really important functionality in `fmt` and not in `error`?&lt;p&gt;And finally we&amp;#x27;ve been encouraged to write `fmt.Errorf(&amp;quot;more description: %v&amp;quot;, err)` (note `%v` not `%w`), so I think there will be a lot of unwrapped errors.&lt;p&gt;...&lt;p&gt;I&amp;#x27;m not sure enough has been thought about the backwards incompatibility. With rclone I try to maintain compatibility with the current go release and a few previous ones so that rclone can remain running with distro go versions and gccgo both of which are a bit behind.  For something as common as error handling this will cause lots of libraries to suddenly be no longer usable with anything less than go1.13.&lt;p&gt;IMHO I think this would be better staying as a non standard library package for the time being while more kinks are worked out.</text></item></parent_chain></comment><story><title>Go 1.13: xerrors</title><url>https://crawshaw.io/blog/xerrors</url></story>