Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
GinkgoRecover now supports ignoring panics that match a specific, hid…
…den, interface
  • Loading branch information
onsi committed Dec 14, 2022
1 parent 60240d1 commit 301f3e2
Showing 1 changed file with 9 additions and 0 deletions.
9 changes: 9 additions & 0 deletions core_dsl.go
Expand Up @@ -369,6 +369,12 @@ func AbortSuite(message string, callerSkip ...int) {
panic(types.GinkgoErrors.UncaughtGinkgoPanic(cl))
}

/*
ignorablePanic is used by Gomega to signal to GinkgoRecover that Goemga is handling
the error associated with this panic. It i used when Eventually/Consistently are passed a func(g Gomega) and the resulting function launches a goroutines that makes a failed assertion. That failed assertion is registered by Gomega and then panics. Ordinarily the panic is captured by Gomega. In the case of a goroutine Gomega can't capture the panic - so we piggy back on GinkgoRecover so users have a single defer GinkgoRecover() pattern to follow. To do that we need to tell Ginkgo to ignore this panic and not register it as a panic on the global Failer.
*/
type ignorablePanic interface{ GinkgoRecoverShouldIgnoreThisPanic() }

/*
GinkgoRecover should be deferred at the top of any spawned goroutine that (may) call `Fail`
Since Gomega assertions call fail, you should throw a `defer GinkgoRecover()` at the top of any goroutine that
Expand All @@ -384,6 +390,9 @@ You can learn more about how Ginkgo manages failures here: https://onsi.github.i
func GinkgoRecover() {
e := recover()
if e != nil {
if _, ok := e.(ignorablePanic); ok {
return
}
global.Failer.Panic(types.NewCodeLocationWithStackTrace(1), e)
}
}
Expand Down

0 comments on commit 301f3e2

Please sign in to comment.