5 ms·

Surprised more people don't talk about panics and third party libraries. So a panic is when something happens that shouldn't and you want the app to just die.

Surprised more people don't talk about panics and third party libraries. So a panic is when something happens that shouldn't and you want the app to just die. But the problem is that third party libraries can do this as well. And there is no way to wrap this behaviour. For example, I used a PDF library that would panic when the file was doing something not in the spec. And rather than me being able to put up a dialog that said "this PDF is invalid" my entire process would die. Not great for a desktop app. It is one of the more insane situations I've ever seen in programming in 30+ years. You literally have to beg third party developers to consider what is best for you rather than them.

Lorak_ 2y ago
I agree that libraries should avoid panicking, but it is not true you can't do anything about it. You can wrap a call to such library into https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
- prmph 2y ago
  > 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.
  - Lorak_ 2y ago
    As far as I know panics abort instead of unwinding in three cases: - When a panic happens during panic unwinding - When the application (not the dependency!) sets panics to abort in Cargo.toml - When the target doesn't support unwinding. Which of those is the case for the desktop app described by the parent?
- threeseed 2y ago
  Did you read the part about types needing to support UnwindSafe. I typically don’t control every type that I am interacting with.
  - DrMeepster 2y ago
    there's a wrapper type, AssertUnwindSafe to get around it. The whole concept of unwind safety was a mistake so don't worry about using it
kfjawdffaw 2y ago
Agreed. Rust crate authors DGAF and plant panics everywhere. Golang package authors are far more panic-averse which I appreciate.
qchris 2y ago
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 2y ago
  > 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 2y ago
    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 2y ago
      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.

Lorak_ 2y ago

I agree that libraries should avoid panicking, but it is not true you can't do anything about it. You can wrap a call to such library into https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

prmph 2y ago
> 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.
- Lorak_ 2y ago
  As far as I know panics abort instead of unwinding in three cases: - When a panic happens during panic unwinding - When the application (not the dependency!) sets panics to abort in Cargo.toml - When the target doesn't support unwinding. Which of those is the case for the desktop app described by the parent?
threeseed 2y ago
Did you read the part about types needing to support UnwindSafe. I typically don’t control every type that I am interacting with.
- DrMeepster 2y ago
  there's a wrapper type, AssertUnwindSafe to get around it. The whole concept of unwind safety was a mistake so don't worry about using it

kfjawdffaw 2y ago

Agreed. Rust crate authors DGAF and plant panics everywhere. Golang package authors are far more panic-averse which I appreciate.

qchris 2y ago

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 2y ago
> 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 2y ago
  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 2y ago
    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.