[qchris]

There's a such a degree of entitlement to this comment.

> And there is no way to wrap this behaviour. [..]

As a sibling comment mentioned, this is possible with std::panic::catch_unwind. That is prominent in the std::panic documentation (literally the first function for std::panic) and if you Google "rust stop panics", the first Stack Overflow result (third down on the page for me) describes this directly. Just about anyone who had put in a modicum of good-faith effort would have found this quickly.

> You literally have to beg third party developers to consider what is best for you rather than them.

I'm assuming this means third-party developers that you're paying and have signed a support contract with? Because if you mean any of the three Rust PDF libraries that I just looked at, those are written by open source developers who have no obligation to consider what is best for you instead of them, owe you exactly nothing, and for whom you should be, if anything, only thanking for doing some of the initial legwork that allows you to use that library at all. If you'd like a change, make a pull request or fork the library.

> It is one of the more insane situations I've ever seen in programming in 30+ years.

Great. You've been in the field a while; nothing written about should surprise you.

[prmph]

> This function might not catch all Rust panics. A Rust panic is not always implemented via unwinding, but can be implemented by aborting the process as well. This function only catches unwinding panics, not those that abort the process.

[qchris]

The default behavior is unwind, and unless the library is targeting something like bare metal embedded, in all likelihood will never resort to an aborting panic.

I'll bet $20 USD to the open source project of your choice that the authors of whatever PDF library was being referenced here did not go out of their way to abort on panic, and that it's just a normal unwind.

[threeseed]

But it stops being a normal unwind if I set panic=abort.

I can legitimately want my app to fail if it’s in a bad state but not have third party libraries do this on my behalf.

[rdsubhas]

Unfortunately, there is a degree of entitlement in this reply as well. You've assumed they don't know what they're talking about, in fact you assumed they don't even know how to Google.

[qchris]

I think you're using the term "assumed" incorrectly. Per Webster's dictionary[1]:

> Presume is used when someone is making an informed guess based on reasonable evidence. Assume is used when the guess is based on little or no evidence.

I'm not assuming they don't know what they're talking about, I'm asserting (or presuming) that they don't know what they're talking about based on supporting evidence showing that it is possible to catch panics. Similarly, I didn't say that they didn't know how to Google. I presumed it was likely they didn't put in a good-faith effort to do so, because in my judgement if they had, it would have been trivial to find the aforementioned information per my experience having just done the same.

[1] https://www.merriam-webster.com/dictionary/assume

[threeseed]

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.

[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.