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
I propose the addition of a go test flag that will add a prefix to the output of t.Error(f) and t.Fatal(f). For example, go test -errlogprefix "Error: " would cause t.Error("it failed") to output Error: it failed.
Alternatively a flag that specifies a template for error message printing would be even more useful, something like -errlogformat "Error: {{.Message}}". Beyond the basic Message field, the context could include additional info such as the location.
Motivation
When the user executes a Go test in vscode (with vscode-go), I want to tell the user what caused the error to fail. vscode provides a mechanism for this - when I report the failure of the test, I can provide messages associated with that failure. However, I have no way of knowing which messages should be associated with the failure. However if this proposal is accepted, I could specify some sequence of bytes as the prefix, and detect that sequence of bytes when processing test output.
The text was updated successfully, but these errors were encountered:
Proposal Details
Proposal
I propose the addition of a
go test
flag that will add a prefix to the output oft.Error(f)
andt.Fatal(f)
. For example,go test -errlogprefix "Error: "
would causet.Error("it failed")
to outputError: it failed
.Alternatively a flag that specifies a template for error message printing would be even more useful, something like
-errlogformat "Error: {{.Message}}"
. Beyond the basic Message field, the context could include additional info such as the location.Motivation
When the user executes a Go test in vscode (with vscode-go), I want to tell the user what caused the error to fail. vscode provides a mechanism for this - when I report the failure of the test, I can provide messages associated with that failure. However, I have no way of knowing which messages should be associated with the failure. However if this proposal is accepted, I could specify some sequence of bytes as the prefix, and detect that sequence of bytes when processing test output.
The text was updated successfully, but these errors were encountered: