8 ms·
Thank you for that link, I thought (production build) rust panic was simply a core dump. I didn't realize there was stack unwinding going on.
by e12e 6y ago
Thank you for that link, I thought (production build) rust panic was simply a core dump. I didn't realize there was stack unwinding going on.
- Tobu 6y agoThere are two options at the moment [1]: - panic=abort (uncatchable) - panic=unwind. With the latter, you would need a catch_unwind at the FFI boundary. [1] https://doc.rust-lang.org/cargo/reference/profiles.html#panic https://doc.rust-lang.org/cargo/reference/profiles.html#pani...
- e12e 6y agoI see. I would think that for a library, in production, all you'd want for panic was a crash. (I guess this is the abort case). AAre the panics being discussed for removal in rust tls "soft" errors that should not crash?
- Tobu 6y agoThere's a categorization here (I don't have access to the triage spreadsheet though): https://github.com/ctz/rustls/issues/447#issuecomment-820719957 https://github.com/ctz/rustls/issues/447#issuecomment-820719... It seems like there's been the most effort on category 4, the ones that can't be reached but can often be proven away with refactoring and typestate. Removing these ensures that the APIs don't expose Result types to callers unnecessarily. Category 1-3 have different severity, but they are all planned to be folded into Result error values.