From ca91ce2d856f79d6cc1cb2d67ed0daef2a89b377 Mon Sep 17 00:00:00 2001
From: Nigel Tao <nigeltao@golang.org>
Date: Fri, 17 Jun 2011 10:51:10 +1000
Subject: [PATCH] doc/effective_go: add a note about prefixing error strings
 with their package name.

R=r, rsc
CC=golang-dev
https://golang.org/cl/4630042
---
 doc/effective_go.html | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/doc/effective_go.html b/doc/effective_go.html
index 0f9b70729e2..9a674c72bfe 100644
--- a/doc/effective_go.html
+++ b/doc/effective_go.html
@@ -233,9 +233,9 @@ Since the whole declaration is presented, such a comment can often be perfunctor
 <pre>
 // Error codes returned by failures to parse an expression.
 var (
-    ErrInternal      = os.NewError("internal error")
-    ErrUnmatchedLpar = os.NewError("unmatched '('")
-    ErrUnmatchedRpar = os.NewError("unmatched ')'")
+    ErrInternal      = os.NewError("regexp: internal error")
+    ErrUnmatchedLpar = os.NewError("regexp: unmatched '('")
+    ErrUnmatchedRpar = os.NewError("regexp: unmatched ')'")
     ...
 )
 </pre>
@@ -2673,6 +2673,13 @@ it is much more informative than the plain
 "no such file or directory".
 </p>
 
+<p>
+When feasible, error strings should identify their origin, such as by having
+a prefix naming the package that generated the error.  For example, in package
+image, the string representation for a decoding error due to an unknown format
+is "image: unknown format".
+</p>
+
 <p>
 Callers that care about the precise error details can
 use a type switch or a type assertion to look for specific