Swift v2 Error Handling

[adonoho]

Gentlefolk,

The Swift v2 try-catch mechanism maps onto Objective-C quite well. Except when there is a shadowing problem.

For example:

- (BOOL)pinWithName:(NSString *)name error:(NSError **)error;

which automatically maps into Swift v2 in [redacted] v7b6 headers as:

public func pinWithName(name: String, error: ()) throws

It should probably map as:

public func pinWithName(name: String) throws

The Objective-C method Is also commonly paired with this shortened form:

- (BOOL)pinWithName:(NSString *)name;

Which maps as:

public func pinWithName(name: String) -> Bool

This short method, I suspect, just calls the main one with a NULL for the NSError**. The signature for the short method is remarkably similar to the Swift throwing method. If I leave the short method in my Objective-C header, then errors ensue:

do { try location.pinWithName(kLocationPin)
    updatePinnedLocations() // Add the locations to the user in the cloud.
}
catch let e as NSError { log.error("Local location save error: \(e)") }

Results in the following compile time warning.

warning: no calls to throwing functions occur within 'try' expression
       do { try location.pinWithName(kLocationPin)
            ^

Obviously, the compiler has chosen the wrong signature. In my own code, where I express a similar pattern, I comment out the short method, then the app compiles just fine.

What is the right way to fix the public API? In most things Swift, the answer would be to get rid of the short Objective-C method.

Or is there a workaround to the above problem? In my own code, I have tried using the NS_SWIFT_NOTHROWS annotation on the long method signature. It allows me to retain my Swift v1.2 error handling code mostly without change.

What would be the right solution for the Parse API?

Anon,
Andrew

[richardjrossiii]

Thanks for the report. I don't have any concrete ideas at this time as to how we should handle this, other than perhaps this is a language issue.

Seeing as we do not yet have a GM of the [redacted] beta, maybe this aspect of Swift will change before the official release.

[adonoho]

Thanks for considering this issue.

While I haven't yet filed a radar with Apple, considering the footprint in the App Store represented by apps using Parse, you might get more attention if you filed with Apple first.

In the meantime, updating your headers to use NS_SWIFT_NOTHROWS is the least invasive change to make to your APIs.

BTW, a trifle more documentation on your build system would be helpful. On my OS X Yosemite box, bundle is not installed. Where would I get it? (I'm trying to edit your headers to see if I can build against v1.8.2 without the short methods.)

[nlutsenko]

Bundler is a simple rubygem - you can run gem install bundler to start using it (it might require sudo to install it first).

[adonoho]

Thank you.

Bundler is now installed.

I have commented out - (BOOL)pinWithName:(NSString *)name; in PFObject.h. As expected, the warning disappears.

[nlutsenko]

Ok, great... I'll look into NS_SWIFT_NOTHROWS for methods that don't have an error, so we can fully support Swift 2.
Since Apple is yet to release Swift 2 with Xcode 7 GM - you can probably expect it by the time iOS 9 GM appears (some rumors suggest Sept 9 as the date).

[adonoho]

This is really Apple's problem. They are either choosing the wrong signature in their warnings processor or are doing worse job. I don't trust their warning. You really should not have to do anything.

[nlutsenko]

I absolutely agree with you, but since error handling in Swift 2 - I think there is not really a need to export the method with no error pointer, since that one is pretty useless and when translated into Swift 2 - both of those will have the same method signature. 😁

[adonoho]

From an Apple forum, the following appears to be the correct solution:

do { try location.pinWithName(kLocationPin, error: ())

It calls the long method and not the short one. The clue was in the auto generated method signature in my OP.

It is ugly beyond words...

[nlutsenko]

I think I found a good solution for it - simply adding NS_SWIFT_UNAVAILABLE("") attribute to methods make the error one have a proper throws annotation and skip error: () behaving the same way as if you simply comment out the original method.

[nlutsenko]

Another awesome piece - that macro seems to be available only with in Xcode 7, meaning that method is still going to be available in Swift 1.2 if someone wants to use it. Seems like we have a plan to go here.