From: Nigel Tao Date: Fri, 17 Jun 2011 00:51:10 +0000 (+1000) Subject: doc/effective_go: add a note about prefixing error strings with their X-Git-Tag: weekly.2011-06-16~2 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=ca91ce2d856f79d6cc1cb2d67ed0daef2a89b377;p=gostls13.git 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 --- diff --git a/doc/effective_go.html b/doc/effective_go.html index 0f9b70729e..9a674c72bf 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
 // 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 ')'")
     ...
 )
 
@@ -2673,6 +2673,13 @@ it is much more informative than the plain "no such file or directory".

+

+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". +

+

Callers that care about the precise error details can use a type switch or a type assertion to look for specific