# Custom \`catch\_unwind\`
**URL:** https://internals.rust-lang.org/t/custom-catch-unwind/15536
**Category:** libs
**Created:** [October 30, 2021, 5:43pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536 "2021-10-30T17:43:29Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@madsmtm](https://internals.rust-lang.org/u/madsmtm)
#### Post date: [October 30, 2021, 5:43pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/1 "2021-10-30T17:43:29Z")
Objective-C have exceptions similar to C++ exceptions (not very familiar with these, maybe some of this applies here as well), and catching them require using the `objc_begin_catch` and `objc_end_catch` helper functions, similar to Rust calling the internal `__rust_panic_cleanup` function as part of [`catch_unwind`](https://doc.rust-lang.org/std/panic/fn.catch_unwind.html).
In the `objc`-crate's exception handling, we currently resort to letting an Objective-C compiler (like `clang`) generate a helper function that uses `@try` and `@catch`. This adds unnecessary overhead, and is bad for cross-compilation and all that.
[`core::intrinsics::try`](https://doc.rust-lang.org/core/intrinsics/fn.try.html) is the underlying intrinsic that makes `catch_unwind` work; with it, the overhead can be avoided by effectively re-implementing most of `catch_unwind`, see an example implementation here: [Use nightly features by madsmtm · Pull Request #11 · SSheldon/rust-objc-exception · GitHub](https://github.com/SSheldon/rust-objc-exception/pull/11/commits/a351a8a2e6bfbde23a397c1f7602cf4f7ae77dea).
But obviously `core::intrinsics::try` is an intrinsic, and not intended to be stabilized, so I'd like to discuss a way we could stabilize it or parts of its functionality, to allow this use-case.
---
### Author:  [@bjorn3](https://internals.rust-lang.org/u/bjorn3)
#### Post date: [October 30, 2021, 7:20pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/2 "2021-10-30T19:20:15Z")
That code doesn't seem correct. It doesn't check that the exception is actually an Objective-C exception and not a Rust panic or C++ exception.
---
### Author:  [@madsmtm](https://internals.rust-lang.org/u/madsmtm)
#### Post date: [October 30, 2021, 7:41pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/3 "2021-10-30T19:41:58Z")
True, though that's not the point, it's meant to be used on the FFI boundary just before sending an Objective-C message (equivalent to calling an `"C-unwind"` function). So the (yup, unsafe) assumption is that any unwinding must be the result of a thrown Objective-C exception.
That said, if there is a way to check the "type" of the exception I'd love to know!
---
### Author:  [@H2CO3](https://internals.rust-lang.org/u/H2CO3)
#### Post date: [October 31, 2021, 8:28am UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/4 "2021-10-31T08:28:53Z")
It seems like you are trying to use Rust panics as traditional, general error handling, like exceptions in other languages. Don't do that – panics are not meant to be used like that. If you want to perform regular error handling, use `Result`.
---
### Author:  [@madsmtm](https://internals.rust-lang.org/u/madsmtm)
#### Post date: [October 31, 2021, 10:59am UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/5 "2021-10-31T10:59:17Z")
Hmm no, rather I'm trying to convert an Objective-C exception into the standard Rust `Result`
---
### Author:  [@kornel](https://internals.rust-lang.org/u/kornel)
#### Post date: [November 1, 2021, 3:44pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/6 "2021-11-01T15:44:27Z")
What do you need from the Rust compiler?
If I'm not mistaken you're assuming that Rust's `try` is going to be compatible with ObjC's `@try`. Is that even a promise that Rust can keep?
---
### Author:  [@mjbshaw](https://internals.rust-lang.org/u/mjbshaw)
#### Post date: [November 1, 2021, 6:10pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/7 "2021-11-01T18:10:55Z")
It might be worth getting involved with the [FFI unwinding working group](https://www.rust-lang.org/governance/teams/lang#wg-ffi-unwind).
---
### Author:  [@InfernoDeity](https://internals.rust-lang.org/u/InfernoDeity)
#### Post date: [November 2, 2021, 11:40am UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/8 "2021-11-02T11:40:21Z")
> [@kornel](#):
>
> If I'm not mistaken you're assuming that Rust's `try` is going to be compatible with ObjC's `@try` . Is that even a promise that Rust can keep?
Yeah, I was going to raise that. There's no guarantee that ObjectiveC and Rust's unwinding mechanisms are related in the slightest, and if you are on a platform where a _de facto_ guarantee does exist, then you probably know how to catch exceptions from the former.
I would like similar abilities, but what is probably needed is a way to directly interact with the unwinding mechanism (SEH on windows, Sys-V/Itanium Unwinding, etc.), which would probably need to be platform-specific.
---
### Author:  [@madsmtm](https://internals.rust-lang.org/u/madsmtm)
#### Post date: [January 5, 2022, 10:20pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/9 "2022-01-05T22:20:16Z")
Coming back to this, I realize that you are right, what I'm trying to do here is fundamentally not possible since Rust's unwinding mechanism is explicitly unspecified, and I think that's the right decision.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [April 5, 2022, 10:21pm UTC](https://internals.rust-lang.org/t/custom-catch-unwind/15536/10 "2022-04-05T22:21:04Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.