Skip to content

Fixed ErrorCode's domain in Swift#1275

Merged
NachoSoto merged 1 commit into
more-obsoletionsfrom
error-domain
Feb 9, 2022
Merged

Fixed ErrorCode's domain in Swift#1275
NachoSoto merged 1 commit into
more-obsoletionsfrom
error-domain

Conversation

@NachoSoto

@NachoSoto NachoSoto commented Feb 9, 2022

Copy link
Copy Markdown
Contributor

Background

In version 3, Objective-C had the constant RCPurchasesErrorDomain (Purchases.ErrorDomain in Swift), manually defined in Objective-C.
This was also visible to Swift through the constant of the same name, and both had the value RCPurchasesErrorDomain.

In version 4, written in Swift, it's not possible to expose global constants to Objective-C. The way the Swift compiler exposes error domains is through the definition of the Error itself.
In our case, it's ErrorCode, which has an @objc name RCPurchasesErrorCode. The compiler appends the word "Domain" to that, creating the new RCPurchasesErrorCodeDomain which superseded RCPurchasesErrorDomain.

However, prior to this change, our implementation of CustomNSError was not overriding errorDomain, so the value of these constants was the default RevenueCat.ErrorCode which was a change (regression) from version 3.x.
Unfortunately because of a bug (https://bugs.swift.org/browse/SR-15841), this isn't enough to fix the domain when ErrorCode is converted to NSError. This PR includes a workaround, but unfortunately the workaround only provides the correct value to Swift.
RCPurchasesErrorCodeDomain will still be the "invalid" RevenueCat.ErrorCode, but this is better than nothing.

At least now we have an explicit domain value for Swift errors, and we're exposing a constant for them (Purchases.ErrorDomain which was already available in version 3, so it's back now).

TLDR:

In version 4 we had lost Purchases.ErrorDomain (which is arguably still useful to Swift), and the value was the auto-generated RevenueCat.ErrorCode instead of the one in version 3 RCPurchasesErrorDomain.
Swift now has a new custom domain RevenueCatErrorDomain which matches Apple's domains like NSCocoaErrorDomain.

@NachoSoto NachoSoto requested review from a team, aboedo and taquitos February 9, 2022 03:08
In version 3, `Objective-C` had the constant `RCPurchasesErrorDomain` (`Purchases.ErrorDomain` in Swift), manually defined in Objective-C.
This was also visible to Swift through the constant of the same name, and both had the value `RCPurchasesErrorDomain`.

In version 4, written in Swift, it's not possible to expose global constants to Objective-C. The way the Swift compiler exposes error domains is through the definition of the `Error` itself.
In our case, it's `ErrorCode`, which has an `@objc` name `RCPurchasesErrorCode`. The compiler appends the word "Domain" to that, creating the new `RCPurchasesErrorCodeDomain` which superseded `RCPurchasesErrorDomain`.

However, prior to this change, our implementation of `CustomNSError` was not overriding `errorDomain`, so the value of these constants was the default `RevenueCat.ErrorCode` which was a change (regression) from version 3.0.
Unfortunately because of a bug (https://bugs.swift.org/browse/SR-15841), this isn't enough to fix the domain when `ErrorCode` is converted to `NSError`. This PR includes a workaround, but unfortunately the workaround only provides the correct value to Swift.
`RCPurchasesErrorCodeDomain` will still be the "invalid" `RevenueCat.ErrorCode`, but this is better than nothing.

At least now we have an explicit domain value for Swift errors, and we're exposing a constant for them (`Purchases.ErrorDomain` which was already available in version 3, so it's back now).

@joshdholtz joshdholtz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

giphy

@NachoSoto NachoSoto merged commit 4b4f4ec into more-obsoletions Feb 9, 2022
@NachoSoto NachoSoto deleted the error-domain branch February 9, 2022 19:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants