1
0
mirror of https://github.com/golang/go synced 2024-11-12 02:20:23 -07:00

testing: panic on calls to Short/Verbose before Parse

CL 121936 added this diagnostic to avoid a panic accessing *short.
(Hence the "This shouldn't really be a panic" comment.)

That CL was right to produce a clearer error than a plain memory fault,
but I think wrong to print+exit instead of panicking. I just ran into
one of these in a real program, and there is no indication anywhere
of how the program reached this point. The panic will show that.
So change print+exit to a panic with a helpful message, in contrast
to the original panic with an unhelpful message and the current
helpful message without stack trace.

Change-Id: Ib2bae1dead4ccde92f00fa3a34c05241ff7690c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/177419
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit is contained in:
Russ Cox 2019-05-15 15:10:32 -04:00
parent 80b393e8b2
commit 6ab049b965

View File

@ -367,11 +367,9 @@ func Short() bool {
if short == nil {
panic("testing: Short called before Init")
}
// Catch code that calls this from TestMain without first
// calling flag.Parse. This shouldn't really be a panic.
// Catch code that calls this from TestMain without first calling flag.Parse.
if !flag.Parsed() {
fmt.Fprintf(os.Stderr, "testing: Short called before flag.Parse\n")
os.Exit(2)
panic("testing: Short called before Parse")
}
return *short
@ -386,13 +384,12 @@ func CoverMode() string {
// Verbose reports whether the -test.v flag is set.
func Verbose() bool {
// Same as in Short.
if chatty == nil {
panic("testing: Verbose called before Init")
}
// Same as in Short.
if !flag.Parsed() {
fmt.Fprintf(os.Stderr, "testing: Verbose called before flag.Parse\n")
os.Exit(2)
panic("testing: Verbose called before Parse")
}
return *chatty
}