[qchris]

> But the point is that I need to now do this with every use of a third party library.

Well, yes. You have to manage your dependencies (by either catching potential panics or forking/modifying them to meet your needs) or accept their behavior. You're using someone else's code for free; this is no one's responsibility but yours, nor is your convenience guaranteed. "This software is provided as is, without warranty" and whatnot.

> And what if I want to set panic=abort on my app to prevent data corruption in my code.

I obviously don't have direct insight into your application, but you could likely use std::process::abort if you feel that data corruption is a risk in a given circumstance (to be fair, I've never personally seen data corruption caused by an unwinding that would have been prevented with an aborting panic instead). Globally setting panic=abort is not necessarily the only approach to achieving your desired behavior.

> Setting panic in an app shouldn’t mean it is applied globally.

You could make a case for a more granular approach to specifying panic behavior. Sure. I don't even disagree with this. But do you see how that's moving the goalposts on your original comment? From "there's no way to wrap this behavior" to "It's possible, but I wish managing this was more convenient for my particular situation."

[threeseed]

> You have to manage your dependencies (by either catching potential panics or forking/modifying them to meet your needs) or accept their behavior

And my point is that I have never had to do this with other languages before.

Rust is the first where I need to actively worry about dependencies.

And there is no way for me to wrap this behaviour in all cases e.g. if I set panic=abort, if the library has unique types that don't support UnwindSafe.