fmt.Errorf() or errors.New()?

<pre><code>// Errorf formats according to a format specifier and returns the string // as a value that satisfies error. fmt.Errorf(format string, a ...interface{}) error </code></pre> <p><strong>OR</strong></p> <pre><code>// New returns an error that formats as the given text. errors.New(text string) error </code></pre> <hr/>**评论：**<br/><br/>kpurdon: <pre><p>They are (nearly) identical under the hood. So if you need to format your error message <code>fmt.Errorf()</code>, if you don&#39;t <code>errors.New()</code>.</p> <p><a href="https://golang.org/src/fmt/print.go#L204">https://golang.org/src/fmt/print.go#L204</a> <a href="https://golang.org/src/errors/errors.go#L9">https://golang.org/src/errors/errors.go#L9</a></p> <p>As a side note <a href="https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully">https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully</a> is a great read on errors.</p></pre>Acidic92: <pre><p>My guess:</p> <pre><code>Speed = errors.New() More Functionality = fmt.Errorf() </code></pre></pre>bgeyts667: <pre><p><a href="https://golang.org/src/fmt/print.go#L204" rel="nofollow">They are completely identical</a>. The only difference is that Errorf allows one to format their error message.</p> <p>Unless you mean, which one to use from code style point of view. If so, then I&#39;d propose to always use custom errors types :)</p></pre>Acidic92: <pre><p>Custom error types that fall under the error interface you mean?</p></pre>bgeyts667: <pre><p>Yes, correct. This way you can provide more information about the error and distinguish one error kind from another on the type level.</p></pre>Acidic92: <pre><p>I&#39;ve explored the depths of Golang (as far as I know), and I understand the fundamentals of interfaces, but the only two things I&#39;ve never used in my code: My own interfaces because I&#39;m too scared of when to use them and I don&#39;t ever see a need for them (although I may be wrong). And, custom errors.</p></pre>goboy123: <pre><p>This helped me a lot.</p> <p><a href="https://dave.cheney.net/paste/gocon-spring-2016.pdf" rel="nofollow">https://dave.cheney.net/paste/gocon-spring-2016.pdf</a></p></pre>lukechampine: <pre><p>I&#39;ve switched to just using <code>pkg/errors</code> everywhere, since it provides both, as well as wrapping errors properly. It annoys me (irrationally) when I have to import both <code>errors</code> and <code>fmt</code> to do error handling.</p></pre>Orange_Tux: <pre><p>A little off-topic, but, i think <code>fmt.Errorf</code> is confusing. People, me included, tend to think that <code>fmt.Errorf()</code> prints something. Instead it returns an error. A good <a href="https://github.com/AdvancedClimateSystems/goldfish/pull/8#discussion_r120100492" rel="nofollow">example is a comment on a PR</a> I got this weekend.</p> <p>I think <code>errors.Newf()</code> is more clear. </p></pre>smasher164: <pre><p><code>errors.New(fmt.Sprintf())</code> is reasonable if you are okay with importing both fmt and errors.</p></pre>winger_sendon: <pre><p>Thats what fmt.Errorf is...</p></pre>smasher164: <pre><p>Lol facepalm</p></pre>