<p>Is there a better way of improving the error handling, too much if err != nil { return //whatever } or at least is there a proposal to improve this in a future golang version?</p>
<hr/>**评论：**<br/><br/>tmornini: <pre><p>I felt the same way.</p>
<p>I was wrong.</p>
<p>Go loves simplicity.</p>
<p>Simplicity breeds reliability.</p>
<p>Imagine writing an application and KNOWING that EVERY error condition was handled properly...</p>
<p>Heaven!</p></pre>earthboundkid: <pre><p>But you can't always know which specific errors a function will return, which can limit your options for dealing with them.</p></pre>tmornini: <pre><p>Same as with every other error handling method.</p></pre>earthboundkid: <pre><p>Checked exceptions and union types let you know what errors are possible, but come with other weaknesses, specifically brittleness. </p></pre>nstratos: <pre><p>In order to improve error handling you need to start thinking of the <a href="https://blog.golang.org/errors-are-values" rel="nofollow">errors as values</a> and start programming with them.</p></pre>gbitten: <pre><p>I feel the same but about the Java's try/catch. There is no perfect error handling, I prefer the Golang way, but I"m ok if you disagree.</p></pre>kpurdon: <pre><p>Go will (likely) not change the core pattern of error handling, and it's verbosity is just something you need to get used to (and I have come to enjoy). However, to extend the error handling functionality you should check out <a href="https://github.com/pkg/errors" rel="nofollow">https://github.com/pkg/errors</a> which HOPEFULLY will make it into stdlib some day soon.</p></pre>Sythe2o0: <pre><p>It may be obvious, but a lot of time can be saved by writing functions that can't return errors, AKA properly compartmenting code bits to keep error-possible regions excluded from functions that just work.</p></pre>jerf: <pre><p>OK, but make sure you're not just writing code that doesn't return errors when it should for convenience's sake. It is more wrong for a function that should return an error to not do so than for function that doesn't have to return an error but does anyway. Eliding errors may seem more convenient at first but it doesn't take long before code written that way becomes the worst of both the "errors as values" and the "exceptions" worlds.</p></pre>chmikes: <pre><p>I hope Go stays as simple as it is. It has all that is needed. What would you consider an improvement ? </p>
<p>There are design patterns that can be used to make the code simpler an more readable. I also use "github.com/pkg/errors" which is handy when I need a stack trace. I must still play with it to find the best way to use it. </p></pre>kaeshiwaza: <pre><p>What's more important is to don't forget to test an error. It's too easy to forget. I user errcheck for that.</p></pre>icholy: <pre><p>The error handling will grow on you. Lack of generics not so much :(</p></pre>tazjin: <pre><p>I like <a href="https://github.com/polydawn/meep" rel="nofollow">meep</a> for slightly more expressive <code>error</code> at least.</p></pre>mrkaspa: <pre><p>Thanks I'll take a look</p></pre>Schpaencoder: <pre><p>How do you use it?</p></pre>nrvale00: <pre><p>This is pretty much the issue which has kept me from adopting golang. I found this a while ago which purports to be a better error handling method than frequent error code checks: </p>
<p><a href="https://davidnix.io/post/error-handling-in-go/" rel="nofollow">https://davidnix.io/post/error-handling-in-go/</a></p>
<p>I've not yet had a chance to digest this but I have a a co-worker who I call "Go Pope" because he's somewhat religious about the tech and he seemed impressed with the above although it was new to him. </p></pre>sethammons: <pre><p>The crux in that link being to have a checkErr method. As the author points out, it makes a lot of sense in a CLI tool, maybe not so much in a server application. </p></pre>bigpigfoot: <pre><p>panic(err)</p></pre>
