On Feb 26, 2016, at 6:12 PM, Jens Alfke <[email protected]> wrote: > On Feb 26, 2016, at 4:48 PM, Quincey Morris > <[email protected]> wrote: >> >> According to NSError documentation: > > <sarc>Thanks, but I did read the documentation before asking.</sarc>
I think Quincey Morris' summary is accurate - at least, it matches my understanding - and complete. The keys defined in NSURLError.h are for errors in the NSURLError domain, which is different from the NSCocoaErrorDomain. The keys containing "FailingURL" should map to objects of type NSURL, and the keys ending in "FailingURLString" should map to objects of type NSString (holding a URL in textual form). IMHO, it's preferable to store a NSURL rather than a NSString-containing-a-URL, but if what you *have* at the point of failure is a string, then it's preferable to store that instead of converting it just to store it. If you're defining your *own* error domain, you can define any keys you like for its info dictionary. Just document them so that users of your library know what to look for. IMHO, the most reasonable / idiomatic options are: - Use NSUnderlyingErrorKey to hold the underlying network error, which presumably contains information about the failing URL. Or just return the underlying error directly, if that makes sense; there isn't any rule that all error returned by calls to your API have to be in your error domain. - Use NSURLErrorKey to hold a NSURL, if the failure has an obvious specific single URL associated with it - Define your own keys to hold whatever diagnostic information (maybe the base URL of the REST API and the relative path and method you invoked, or something like that) - Don't supply any of these, if there isn't anything that the caller can do with the information > On Feb 26, 2016, at 4:53 PM, [email protected] wrote: >> It seems like the shorter one would be for a "click here to see more >> information or open this file URL” > > Oh god, that possibility hadn’t even occurred to me — some kind of link to > put into the alert? I don't think there's any reason to think that's the intent of these keys. If you want to provide an option like that, I think the thing to do is either a help anchor or a recovery attempter. If you want to supply a readable message for the case that your caller doesn't handle the error but simply presents it to the user, provide the NSLocalized{Description,FailureReason}Keys, either directly when you create the error, or via the userInfoProvider for your framework's error domain. Wim. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
