1
0
mirror of https://github.com/golang/go synced 2024-11-23 16:10:05 -07:00

effective go: explain the effect of repanicking better.

Also fix a <p> error in go_spec.html.

Fixes #1370.

R=rsc, gri
CC=golang-dev
https://golang.org/cl/3835043
This commit is contained in:
Rob Pike 2011-01-05 11:39:57 -08:00
parent 0f26608ebc
commit 29d0f02bd2
2 changed files with 14 additions and 3 deletions

View File

@ -2792,7 +2792,7 @@ user-triggered errors.
</p>
<p>
With this error handling in place, the <code>error</code> method
With error handling in place, the <code>error</code> method
makes it easy to report parse errors without worrying about unwinding
the parse stack by hand.
</p>
@ -2804,6 +2804,17 @@ Useful though this pattern is, it should be used only within a package.
to its client. That is a good rule to follow.
</p>
<p>
By the way, this re-panic idiom changes the panic value if an actual
error occurs. However, both the original and new failures will be
presented in the crash report, so the root cause of the problem will
still be visible. Thus this simple re-panic approach is usually
sufficient&mdash;it's a crash after all&mdash;but if you want to
display only the original value, you can write a little more code to
filter unexpected problems and re-panic with the original error.
That's left as an exercise for the reader.
</p>
<h2 id="web_server">A web server</h2>

View File

@ -3973,9 +3973,9 @@ As with an assignment, the operands on the left must be
<a href="#Address_operators">addressable</a> or map index expressions; they
denote the iteration variables. If the range expression is a channel, only
one iteration variable is permitted, otherwise there may be one or two.
<p>
</p>
<p>
The range expression is evaluated once before beginning the loop.
Function calls on the left are evaluated once per iteration.
For each iteration, iteration values are produced as follows: