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

doc/effective_go.html

@@ -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>
 

doc/go_spec.html

@@ -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: