Realm-cocoa: Realm Internal Error Class

Created on 11 Aug 2016  路  3Comments  路  Source: realm/realm-cocoa

As in Swift 3 ErrorType has been named to Error, it conflicts with your internal Error class and so if I want to create my own Error enum as follows I get an ambiguous error from the debugger.

public enum UserServiceError: Error {
case UnableToRetrieveUser
case UnableToCreateUser
case UnableToParseUser
case NoCurrentUser
}

Please rename your internal Error.

We LOVE to help with any issues or bugs you have!

Questions: If you have questions about how to use Realm, ask on
StackOverflow.
We monitor the realm tag.

Feature Request: Just fill in the first two sections below.

Bugs: To help you as fast as possible with an issue please describe your issue
and the steps you have taken to reproduce it in as many details as possible.

Thanks for helping us help you! :-)

Please remove this line and all above before submitting.

Goals

What do you want to achieve?

Expected Results

What did you expected to happen?

Actual Results

What did happened instead?
e.g. the stack trace of a crash

Steps to Reproduce

What are steps we can follow to reproduce this issue?

Code Sample

Provide a code sample or test case that highlights the issue.
If relevant, include your model definitions.
For larger code samples, links to external gists/repositories are preferred.
Alternatively share confidentially via mail to [email protected].
Full Xcode projects that we can compile ourselves are ideal!

Version of Realm and Tooling

In the CONTRIBUTING guidelines, you will find a script,
which will help determining these versions.

Realm version: ?

Xcode version: ?

iOS/OSX version: ?

Dependency manager + version: ?

T-Help swift

Most helpful comment

My take on this is that since the Swift standard library makes use of many standard terms, conflicts will inevitably arise between types it provides and types provided in third-party frameworks. Module namespaces provide a way around this that's cleaner than prefixes on type names like in Objective-C, or giving types unnatural names to avoid conflicts. I'm not sure how others feel about this though.

All 3 comments

You can avoid the ambiguity by qualifying the base class with a module name. In your case, that'd be by specifying the base class as Swift.Error.

Thanks for the fast response! Did not see that, my mistake.

My take on this is that since the Swift standard library makes use of many standard terms, conflicts will inevitably arise between types it provides and types provided in third-party frameworks. Module namespaces provide a way around this that's cleaner than prefixes on type names like in Objective-C, or giving types unnatural names to avoid conflicts. I'm not sure how others feel about this though.

Was this page helpful?
0 / 5 - 0 ratings