Panic Hook Removal

[AzureMarker]

Can someone remind me why we removed the panic hook? What's the expected behavior right now? It doesn't look like we have a panic hook implementation somewhere else.

39bd6c2
cc @Meziu

[Meziu]

The panic hook implementation was removed because, as it stood, it had to make way too many assumptions about the application’s context, some that often fell into unsafety or possible double panics. It was decided to leave the panic hook implementation to the final user, if they desired to have one.

[AzureMarker]

It seems useful to still offer some sort of "simple" panic hook. Right now the user experience is that the application immediately crashes.

[Meziu]

Anything more complex than just printing the backtrace would require some assumptions about the context or somewhat excessive setups. For example, waiting on input means we have to use Hid, which uses global mutable states and thus can’t be safely accessed across threads (yay!). Tbh, the only setup that wouldn’t require anything special is std::thread::sleep, but even that could cause issues sometimes…

Also, let’s not forget the fact that the “user experience” of returning to the Homebrew Menu is still much better than the ARM panics one would get when using the normal C stuff 😛.

[ian-h-chamberlain]

@AzureMarker are you suggesting we provide something like this? Basically giving the user an opt-in to the old behavior?

pub fn panic_handler(main_thread: ThreadId) -> impl Fn(&PanicInfo<'_>) {
    move |info: &PanicInfo| {
        if main_thread == std::thread::current().id() && console::Console::exists() {
            eprintln!("\nThe software will exit in 5 seconds");
            std::thread::sleep(std::time::Duration::from_secs(5));
        }
    }
}

I was thinking... maybe there's a thread-safe way we could wait for button presses or something via svcSignalEvent? I haven't really used the event APIs at all but it seems like maybe we could have some kind of event that it waits on (like a button press) in the panic handler?

There's also a bunch debug stuff in libctru e.g. ExceptionEvent which might be relevant, although it seems sparsely documented so I'm not sure exactly what those are used for. Maybe more related to the kinds of CPU exceptions that Luma3DS handles...

[AzureMarker]

Yeah just some easy to use, simple panic handler so the user doesn't need to implement their own for a basic application. It's a lot to ask someone just getting started to implement a panic handler just to see why their hello world is crashing.

[ian-h-chamberlain]

Just to revisit this discussion, a new panic hook implementation has arisen with #162 !

Personally I think that looks a lot cleaner and is using the 3DS native UI to pause execution, which seems like a major benefit over the awkward SELECT loop we had previously. As long as we can make sure it's safe, I think that makes sense to expose as the "basic" panic API we expose.