Suppress panic message


Is it possible to suppress printing of a panic message (“thread panicked at”)?

I have a parent superviser thread which launches a child thread.

The child can sometimes panic, but is safe to just restart.

So I don’t want to see the default panic message in the stderr and instead I want to provide my own reporting. I know that at least on nightly I can provide my own panic handler (and mess something up along the way :slight_smile: ), but it seems like a too complex solution for my use case.


IIRC, you must use the unstable as you mentioned, and that is the only way.


What rustc and libtest do is interesting. They call io::set_panic, an undocumented function, making all of stderr go nowhere.


+1 for ability to customise a panic message.
In expectest I’m using panicking::panic_fmt (here). It’s all good but without “thread panicked at” it would be better.
I also think that std::panic::set_hook is overkill for me.


A bit late to this thread, but I’d like to present you with panic_control::spawn_quiet():


Oh, and this even works on stable because set_hook is now stable? Nice! :heart:


I understood the philosophy that panics in rust are never on purpose and exception handling is not mature enough in rust and not always possible. Result with either item value or an error is the way to handle errors, the rest (panic and assertions) are not bona fine errors. Am I missing something?


The crate is basically a test harness helper, used to test how code behaves under a panic.
Indeed, it should not be used in any production-destined software (but see below). That said, in Rust, catching a panic on a thread boundary is a valid failure isolation mechanism. There is also catch_unwind, which definitely should not be used for this purpose; its only legitimate use is to prevent unwinding into non-Rust code.

By “bona fide errors” I meant fatal conditions that cause “real” panics. These need to be distinguished from the simulated panic under test, in that a thread that calls join() on the panicked thread’s handle should still get an Err if the panic is not of the expected type.


That’s a bit strong statement. Some parts of it, like spawn_quiet and ThreadResultExt, can indeed be used wherever they are needed, such as the use case described at the beginning of this topic.


I think this is a bit too strong of a statement. catch_unwind can be used to create “less-than-a-thread” isolation boundaries within application itself. For example, one might want to isolate independent async tasks.

Here are some legitimate usages of catch_unwind from the futures crate:✓&q=catch_unwind