Panic handlers and order precedence?

[JoshLind]

Reading the standard library documentation for panic, one might think that catch_unwind (https://doc.rust-lang.org/std/panic/fn.catch_unwind.html) would take precedence over any registered panic hook, i.e., if you used both catch_unwind and set_hook in a program, any unwinding panic thrown in the catch_unwind scope should be caught. But, this doesn't appear to be the case. See this simple example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a0167a26203b23f5b50efcd1478b54d7

fn bar() {
    println!("bar() is called!");
}

fn foo() {
    let res = std::panic::catch_unwind(|| {
        bar();
        panic!("Panicking after calling bar()!");
    });
    
    println!("Unwind closure returned: {:?}", res);
}

fn main() {
    std::panic::set_hook(Box::new(move |_| {
        println!("Panic handler invoked!");
        std::process::exit(12);
    }));
    
    foo();
}

I'd expect Unwind closure returned: Err(Any { .. }) to be printed, but it doesn't get printed. Instead, the panic handler is invoked.

Can you elaborate if this is the correct behaviour/intent? And if so, why? It seems to me that it would be useful to support both concurrently, i.e., allow the catch to handle the panic, and if it cannot, it could fallback to the registered handler?

[albertlarsan68]

As written in https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html:

The panic hook is invoked when a thread panics, but before the panic runtime is invoked. As such, the hook will run with both the aborting and unwinding runtimes.

This means that the panic hook is run before the stack is unwound, thus before the catch_unwind catches the panic.

[JoshLind]

Hey @albertlarsan68, thanks for replying 😄

This means that the panic hook is run before the stack is unwound, thus before the catch_unwind catches the panic.

Aah, gotcha. Yeah, we managed to see this on our side, too. It might be worth having the docs make this super explicit, especially for n00bs like me (e.g., I wasn't able to infer the current behaviour from this sentence). I also assume having them operate the other way around is undesirable and/or infeasible?

[albertlarsan68]

@rustbot claim

A PR to document this behavior is up at #105497