You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
n/a
What did you see instead?
n/a
A common use of fmt.Errorf is to wrap a generic error returned from an upstream library so you can see where it occurred in your code:
x, err := something.DoThing()
if err != nil {
return nil, fmt.Errorf("Failed to do thing here: %s", err)
}
Concatenation in other variadic functions in fmt seems to be slightly faster than processing format strings, and in the case of wrapping errors, needs less syntax.
I could write:
x, err := something.DoThing()
if err != nil {
return nil, fmt.Error("Failed to do thing here: ", err)
}
The differences are only marginal, but it does fit with the pattern of a lot of the other functions in fmt, one that's just variadic and one that takes a format string.
The text was updated successfully, but these errors were encountered:
ianlancetaylor
changed the title
Feature request: Should we have fmt.Error() as well as fmt.Errorf()?
fmt: feature request: add Error, which corresponds to Errorf as Print corresponds to Printf
Nov 22, 2017
bradfitz
changed the title
fmt: feature request: add Error, which corresponds to Errorf as Print corresponds to Printf
proposal: fmt: feature request: add Error, which corresponds to Errorf as Print corresponds to Printf
Nov 22, 2017
It's already a little confusing that fmt.Errorf returns an error and log.Errorf prints a line of text to stderr. And .Error means other things in other APIs. Let's not compound this by adding fmt.Error here.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.9 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/alandaws"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.9/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.9/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/06/jjq25lws0cbcxv37ns0hb_mm0000gn/T/go-build733634811=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
What did you do?
Nothing, feature request
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
n/a
What did you see instead?
n/a
A common use of
fmt.Errorf
is to wrap a generic error returned from an upstream library so you can see where it occurred in your code:Concatenation in other variadic functions in fmt seems to be slightly faster than processing format strings, and in the case of wrapping errors, needs less syntax.
I could write:
The differences are only marginal, but it does fit with the pattern of a lot of the other functions in fmt, one that's just variadic and one that takes a format string.
Using Dave Cheney's errors.Wrap is possibly a better approach altogether: https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
Do people think a
fmt.Error
function is valuable?The text was updated successfully, but these errors were encountered: