How to detect panic(nil) and normal execution in deferred function Go?

The go runtime can detect panic(nil) and reports an error.

However, I can't detect panic(nil) with recover() in a deferred function because it returns nil, so I cannot differentiate it from normal execution (no panic) as I would test for
the return value of recover() to be nil.

For example,

defer func(){
    var err = recover()
    if err != nil {
       // Real serious situation. Panic from inner code.
       // And we may have some critical resources which 
       // must be cleaned-up at any cases.
       // However, this will not be executed for panic(nil) 

       rollback()

       // I am still not sure that how should I treat `panic`…
       // Should I just ignore them?
    }
}()

var err = doTransaction()
if err == nil {
    commit()    // Happy case.
} else {
    rollback()  // Regular execution. Just a lucky case.
}

ROLLBACK is just an example, and I think I can have plenty of critical cases needs cleanup. Well, those cleanup code won't be executed on real program crash too, but I want to defend as much as possible.

How can I detect any panic regardless of its parameter in a deferred function?

I simply can set a flag before exit.

AFAIK, panic is goroutine-specific, and single goroutine is guaranteed to be in single thread. So synchronization/locking is not required around variable ok. If I'm wrong, please correct me.

func clean(ok *bool) {
	if *ok {
		log.Printf("Execution OK. No panic detected.\n")
	} else {
		var reason = recover()
		log.Printf("Some bad thing happen. reason = %v\n", reason)
		panic("Abnormal exit. Program abandoned. Stack-trace here.")
		debug.PrintStack() // Oops. this will not run.
	}
}

func main() {
	var ok bool = false

	defer clean(&ok)
	panic(nil)

	test1() // Here's the main job.

	ok = true
	log.Printf("All work done. Quit gracefully.\n")
}

Unless I misunderstood your question, deferred function calls will run when panicking, even if the value passed was nil. This is illustrated by the following program:

package main

import "fmt"

func main() {
	defer func() {
		fmt.Println("Recover:", recover())
	}()
	panic(nil)
}

You can therefore easily detect if panic(nil) happened by comparing the value returned by recover() to nil.

Edit to answer comment:

Yes, that's true; deferred calls will normally run when a function returns. But they are also run when unwinding the call-stack after a panic().

Edit after question was updated:

You are correct that there is no way to differentiate these cases. On the other hand, panicking with nil doesn't make much sense either - especially because of this limitation.

The only use-case for panic(nil) that I could think of would be to deliberately avoid recovery and force the program to crash with a stack trace. There are more elegant ways to do that though, using the runtime package for instance.

Check if the proposal 25448 "spec: guarantee non-nil return value from recover" can help.
>
> Calling panic with a nil panic value is allowed in Go 1, but weird.
>
> Almost all code checks for panics with:
>
> go
> defer func() {
> if e := recover(); e != nil { ... }
> }()
>
> ... which is not correct in the case of panic(nil).
>
> The proper way is more like:
>
> go
> panicked := true
> defer func() {
> if panicked {
> e := recover()
> ...
> }
> }()
> ...
> panicked = false
> return
> ....
> panicked = false
> return
>
>
> Proposal: make the runtime panic function promote its panic value from nil to something like a runtime.NilPanic global value of private, unassignable type:
>
> go
> package runtime
>
> type nilPanic struct{}
>
> // NilPanic is the value returned by recover when code panics with a nil value.
> var NilPanic nilPanic
>

Proposed in 2018, it just got accepted (Jan. 2023)

> The current proposal is that starting in Go 1.21 (say),
panic(nil) turns into panic(&runtime.PanicNil{}) during panic (so a variable that happens to be a nil interface does it too, not just the literal text panic(nil)).
>
>panic(nil) is always OK, but recover() returns &runtime.PanicNil{} instead of nil after this change.
If GODEBUG=panicnil=1, then this change is disabled and panic(nil) causes recover() to return nil as it always has.
>
> Assuming #56986 ("proposal: extended backwards compatibility for Go") happens too in Go 1.21, this behavior would only change in modules that say 'go 1.21' in the work module (top-level go.mod).
So when you update from Go 1.20 to Go 1.21, without changing any go.mod lines, you'd still get the old panic(nil) behavior.
When you change your top-level go.mod to say go 1.21, then you get the new behavior, in the whole program.

For most cases, the idiomatic way of if recover() != nil works, but for robustness, or when executing third-party code, it should not be used, because it does not detect panic(nil).

This pattern is how you can check it:

func checkPanic(action func()) (panicked bool, panicMsg interface{}) {
    panicked = true
    defer func() { panicMsg = recover() }
    action()
    panicked = false
    return
}

If action() panics, then the line below is never executed, and panicked stays true.
You can check it using the above helper function as follows:

if panicked, msg := checkPanic(func() { /* ... */ }); panicked {
    // handle panic...
} else {
    // happy case :D
}

Or you can directly implement the pattern into the function you want to check, but it might turn out way messier that way.