|
|
|
|
|
|
by threeseed
524 days ago
|
|
|
I am aware of being able to catch panics. But the point is that I need to now do this with every use of a third party library. And for example with pdf-rs it was happening on relatively minor things e.g. incorrect date format. And what if I want to set panic=abort on my app to prevent data corruption in my code. Setting panic in an app shouldn’t mean it is applied globally. |
|
|
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."