<p>It would appear that some people at StackOverflow think that asking people leaving Go code in answers to at least use <code>v, err := …</code> instead of <code>v, _ := …</code> is too onerous. :(</p>
<p>Edit: Opps, lost the link: <a href="http://meta.stackoverflow.com/q/290223/55504">http://meta.stackoverflow.com/q/290223/55504</a> and <a href="http://meta.stackoverflow.com/a/290224/55504">http://meta.stackoverflow.com/a/290224/55504</a></p>
<hr/>**评论：**<br/><br/>elithrar_: <pre><p>Hah, I saw your comment discussion on SO with another user about this. I agree with you - ensuring your example code handles errors in an environment <em>guaranteed</em> to have newbies is really useful.</p>
<p>I don't think anyone is expecting some vast error-handling logic that distracts from the problem, but either:</p>
<pre><code>a, err := someFunc()
// handle error
</code></pre>
<p>or...</p>
<pre><code>b, err := someFunc()
if err != nil {
// handle error
{
</code></pre>
<p>... is not inappropriate. </p></pre>dchapes: <pre><p>Indeed. I was surprised at the slight backlash (or perhaps I imagined this) to this suggestion. The answer on which I commented (not the first) about this was "fixed" just by changing <code>, err</code> from <code>, _</code> one place and adding <code>err =</code> to a <code>rows.Scan</code> call. Hardly too much to ask for IMO and yet making a big difference (again IMO).</p>
<p>I wonder if perhaps some people thought I was implying that nothing should be simplified or some such.</p>
<p>With respect to Go I also don't get those that said that "it's distracting". Shouldn't all good Go code have the appropriate level of error checking? Does this mean that we're constantly being distracted when reviewing/looking-at Go code? (Some of course think so, some even think the solution is exceptions or some such). If we're used to typing it in, and if we're used to seeing it, then why shouldn't it be in all answers? Of course I use short-cuts like <code>log.Fatal(err)</code> much more on SO then in "real code".</p>
<p>Perhaps those that were downvoting me on SO aren't aware of how common it is to see "newbies" cut-n-paste code they don't understand. It's fine to say that's foolish and they deserve what they get but this doesn't just effect them; it effects everyone that tries to help them (here, on SO, on go-nuts, at the workplace, whatever) when they waste everyone's time asking why they get "some random panic" in their code and don't realize they have <code>f, _ := os.Open("filenam")</code> and made a typo on the filename.</p>
<p>I wonder if some of these people even know what <code>_</code> means or if they think it's just some magic invocation they "need to do" because "that guy on the blog I read did it!". One of my pet peeves is seeing anyone <em>ever</em> do something like <code>y, _ := x.(int)</code>; I can only think of one extremely rare case where using the two valued version of a type assertion but ignoring the bool wouldn't be out-right wrong. (But I've seen exactly that repeatedly on SO!)</p>
<p></rant> :)</p></pre>DavidDavidsonsGhost: <pre><p>Why is the second example not appropriate? Seems pretty clear what you need to do. Error handling is its own topic and something the devneeds to think about.</p></pre>the_starbase_kolob: <pre><p>He said it's not inappropriate </p></pre>Bromlife: <pre><p>Loost the link?</p></pre>dchapes: <pre><p>I screwed it up. I normally don't start reddit posts, I meant this to be a link post but I mistakenly switched it to a text post without realising that completely removed the link I had entered. At least I noticed right away and immediately edited the link into the text.</p></pre>Bromlife: <pre><p>Sorry, I was being a dick and making fun of the "loosing" typo in your title.</p>
<p>It's one of my pet hates when people say loosing instead of losing.</p></pre>anoland: <pre><p>Coming from PHP land, where there are tons of bad examples, I think it ultimately doesn't matter. It isn't your job to make sure somebody else's code compiles or is even safe. The onus is on the programmer to make sure that their work is working and is safe in their environment. Excessively harping on them about handling errors, or down voting an otherwise helpful answer isn't conducive to someone learning something new.</p>
<p>Edited to add: unless the question is specifically about how to handle some <del>error</del> boilerplate problem, ignoring boilerplate should be fine.</p></pre>dchapes: <pre><p>I somewhat agree but on the other hand I can't stand the outright incompetence I see all around the software industry. And it may not be my job but it is my (and everyone's) problem when we have to use software written by people that are barely competent.</p>
<p>I'm reminded of:</p>
<blockquote>
<p>Weinberg's Second Law:
If builders built buildings the way programmers wrote programs,
then the first woodpecker that came along would destroy civilization.
-- Gerald Weinberg</p>
</blockquote></pre>klaaax: <pre><p>Yes it does matter. You need to educate people or general go code quality will go down. If you behave a like an error handling nazi ,that will piss off people a bit, but they will behave like this themselves after sometime, because they know it really matters.</p></pre>: <pre><p>[deleted]</p></pre>dchapes: <pre><p>IMO if the example is incomplete than it's fine for it not to compile (e.g. just giving a handful of lines as example of how to use some package or something) and that clues in the would be copy-n-paster that it is incomplete. (i.e. even without the comment I prefer your first example).</p>
<p>If the example is complete or is meant to compile (or be run on the playground) than it should probably at least have a <code>panic(err)</code> (I prefer <code>log.Fatal(err)</code> for examples) or <code>return (err)</code>. It's really not much to write (we're all used to it) and it's really not too distracting (after all, the code we look at all the time does this and it doesn't distract us).</p>
<p>And if you're writing a complete example for the playground you tested that it runs correctly, right? That often means having checked the errors (unless, unlike me, you never make a mistake while assembling your example).</p></pre>gogolang: <pre><p>I could go either way on this. I'm inclined to say errors should be ignored for the sake of brevity unless the error has to do with the question. </p>
<p>If someone has to investigate a bug that has nothing to do with the error, it's easier to look through code that ignored the error checking.</p>
<p>For example, for questions related to something like Read in <a href="http://golang.org/pkg/io/#Reader" rel="nofollow">io.Reader</a>
where error value doesn't just take a nil/non-nil value, it makes sense to take the err value and do something with it.</p>
<p>On the other hand, if someone on StackOverflow is just doing this:</p>
<pre><code>if (err != nil) {
fmt.Printf("err=%s\n, err)
return
}
</code></pre>
<p>That's just 4 useless boilerplate lines. </p>
<p>EDIT: Dammit, I can't get reddit to show the line breaks in the code block</p></pre>mwholt: <pre><p>I have mixed feelings about this. It depends who your audience is, I think, and the audience varies <em>greatly</em> on Stack Overflow. Basically, if you know your audience is mainly experienced Go programmers, you can focus the example on relevant code by ignoring errors (for the sake of brevity in a code snippet).</p>
<p>If the reader is a newbie, though, it's more likely that they'll forget to handle the error if the snippet doesn't. On the other hand, if you do handle the error in your code snippet, though, the reader may forget to change it to accommodate their program. In the latter case, you've essentially assumed that you know better than the reader how to how to handle errors for the reader's situation which you actually know nothing about. It also makes the snippet more confusing, since who knows -- especially a newbie -- if the way you've handled the error is essential for the snippet to work correctly! (For example, continuing program execution through <code>log.Println</code> vs. terminating it with <code>log.Fatal</code>.)</p>
<p>I think a comment to <code>// handle err</code> is appropriate and, I daresay, the snippet ought not compile on its own until the reader (the "copier+paster") modifies it so that <code>err</code> is not declared and unused any more.</p></pre>sigmonsays: <pre><p>Please spell losing..you're not loose..</p></pre>dchapes: <pre><p>D'oh, sorry. Reddit doesn't let me edit title text. I'll be more careful next time I post.</p></pre>
