Catching NSException


(Jon Brooks) #1

Apologies if this has come up before - I've fallen behind in following this
list.

I recently ran into an issue where I needed to be able to catch
NSExceptions raised by Objective C API in Swift, and found no good way to
do that. Currently the only possible way is to via Objective C code that
wraps the call in an Objective C style @try/@catch block. If building a
swift framework, this means a separate module, since we can't use bridging
headers.

My quick attempt at a workaround can be seen here:
https://github.com/jonbrooks/ObjCTryCatch and there are other workarounds
out there too. I wondered if there has been any discussion to building
something like this into swift directly. I don't really have any good
ideas, but maybe something like

    do {
        objc_try someObjectiveCInstance.methodThatMightRaiseException()
    } catch {
        //error would be an ErrorType that contains info about the
exception raised, or the exception itself?
    }

Any thoughts?


(Joe Groff) #2

Catching ObjC exceptions is problematic, since Cocoa generally only uses exceptions for unrecoverable programmer error situations, and most ObjC code does not attempt to clean up resources or maintain invariants in response to exceptions unwinding through it. Generally the best answer is restructure your code not to cause the exception to be thrown in the first place. There are unfortunately some APIs for which that's not possible, but if you must handle ObjC exceptions, I'd recommend doing so from ObjC code rather than from Swift.

-Joe

···

On Mar 24, 2016, at 11:06 AM, Jon Brooks via swift-evolution <swift-evolution@swift.org> wrote:

Apologies if this has come up before - I've fallen behind in following this list.

I recently ran into an issue where I needed to be able to catch NSExceptions raised by Objective C API in Swift, and found no good way to do that. Currently the only possible way is to via Objective C code that wraps the call in an Objective C style @try/@catch block. If building a swift framework, this means a separate module, since we can't use bridging headers.

My quick attempt at a workaround can be seen here: https://github.com/jonbrooks/ObjCTryCatch and there are other workarounds out there too. I wondered if there has been any discussion to building something like this into swift directly. I don't really have any good ideas, but maybe something like
    
    do {
        objc_try someObjectiveCInstance.methodThatMightRaiseException()
    } catch {
        //error would be an ErrorType that contains info about the exception raised, or the exception itself?
    }

Any thoughts?


(E. Maloney) #3

Hi Jon,

I ran into a similar situation and needed a way to not only catch NSExceptions from Swift, but throw them as well. If it would he useful to you, it's part of the open-source CleanroomBridging module, which is intended to ease a few Swift/ObjC interoperability issues. The header file for the exception-related code is here:

https://github.com/emaloney/CleanroomBridging/blob/master/Sources/Exception.h

It is included in the module's bridging header, so you can use it from Swift.

Evan

···

On Mar 24, 2016, at 2:06 PM, Jon Brooks via swift-evolution <swift-evolution@swift.org> wrote:

Apologies if this has come up before - I've fallen behind in following this list.

I recently ran into an issue where I needed to be able to catch NSExceptions raised by Objective C API in Swift, and found no good way to do that. Currently the only possible way is to via Objective C code that wraps the call in an Objective C style @try/@catch block. If building a swift framework, this means a separate module, since we can't use bridging headers.

My quick attempt at a workaround can be seen here: https://github.com/jonbrooks/ObjCTryCatch and there are other workarounds out there too. I wondered if there has been any discussion to building something like this into swift directly. I don't really have any good ideas, but maybe something like
    
    do {
        objc_try someObjectiveCInstance.methodThatMightRaiseException()
    } catch {
        //error would be an ErrorType that contains info about the exception raised, or the exception itself?
    }

Any thoughts?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Goffredo Marocchi) #4

Thank you!!!

[[iOS messageWithData:ideas] broadcast]

···

On 1 Apr 2016, at 20:04, Evan Maloney via swift-evolution <swift-evolution@swift.org> wrote:

Hi Jon,

I ran into a similar situation and needed a way to not only catch NSExceptions from Swift, but throw them as well. If it would he useful to you, it's part of the open-source CleanroomBridging module, which is intended to ease a few Swift/ObjC interoperability issues. The header file for the exception-related code is here:

https://github.com/emaloney/CleanroomBridging/blob/master/Sources/Exception.h

It is included in the module's bridging header, so you can use it from Swift.

Evan

On Mar 24, 2016, at 2:06 PM, Jon Brooks via swift-evolution <swift-evolution@swift.org> wrote:

Apologies if this has come up before - I've fallen behind in following this list.

I recently ran into an issue where I needed to be able to catch NSExceptions raised by Objective C API in Swift, and found no good way to do that. Currently the only possible way is to via Objective C code that wraps the call in an Objective C style @try/@catch block. If building a swift framework, this means a separate module, since we can't use bridging headers.

My quick attempt at a workaround can be seen here: https://github.com/jonbrooks/ObjCTryCatch and there are other workarounds out there too. I wondered if there has been any discussion to building something like this into swift directly. I don't really have any good ideas, but maybe something like
    
    do {
        objc_try someObjectiveCInstance.methodThatMightRaiseException()
    } catch {
        //error would be an ErrorType that contains info about the exception raised, or the exception itself?
    }

Any thoughts?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution