[swift-evolution] [Review] SE-0112: Improved NSError Bridging

[Douglas Gregor]

> On Jul 4, 2016, at 10:15 PM, Ben Rimmington <me at benrimmington.com> wrote:
> 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md>
> 
> If <Foundation/NSError.h> uses NS_EXTENSIBLE_STRING_ENUM for `domain` names and `userInfo` keys, would a generic type (cf. DispatchSpecificKey) also be possible?
> 
> 	FOUNDATION_EXPORT NSErrorUserInfoKey<NSNumber> const NSStringEncodingErrorKey;
> 	FOUNDATION_EXPORT NSErrorUserInfoKey<NSURL>    const NSURLErrorKey;
> 	FOUNDATION_EXPORT NSErrorUserInfoKey<NSString> const NSFilePathErrorKey;
> 
> This could provide a more typesafe API, without the need for typed accessors in each SDK overlay.
> 
> 	func userInfoValue<Value>(forKey: NSError.UserInfoKey<Value>) -> Value?

This is complicated by the fact that userInfo keys don’t have to be strings, so making the type stronger may not be possible. 

That technicality aside, why? While NSError itself is centered around userInfo, Swift errors are not: they’re strongly-typed values for which one would expect to have accessors to get additional information about the errors. One would not define new userInfo keys in Swift nor (directly) define new error domain strings, except to refer to those errors from Objective-C code. In many ways, that’s the goal of this proposal: to take away the need for Swift programmers to think about NSError’s domain/code/userInfo by providing type-safe, easy-to-use APIs. In that context, it seems unfortunate to restyle something that Swift programmers shouldn’t have to use.

> 
> The following comment is incorrect, AFAIK. The `helpAnchor` is the name attribute of a HTML anchor element.
> 
> 	/// A localized message providing "help" text if the user requests help.
> 	var helpAnchor: String? { get }

Apple’s documentation says:

NSHelpAnchorErrorKey
The corresponding value is an NSString containing the localized help corresponding to the help button. See helpAnchor <https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSError_Class/#//apple_ref/occ/instp/NSError/helpAnchor> for more information.

Available in OS X v10.6 and later.

> 
> Also in the LocalizedError protocol, should the `errorDescription` property return a non-optional String, to match the NSError API?

No; one can omit the errorDescription property (which is tantamount to omitting the NSLocalizedDescriptionKey value in NSError’s userInfo) and Cocoa will create a default.

> 
> Should there be an API for non-localized errors? This is currently available in <CoreFoundation/CFError.h> using kCFErrorDescriptionKey.

IMO, no. Leave it at the defaults or do it correctly.

> 
> If error recovery and help anchors are only available in macOS, should there be conditional #if os(macOS) blocks?

Practically speaking, this 

> 
> Is the `errorDomain` property of CustomNSError allowed to vary its result? For example:
> * an SQLite error <https://www.sqlite.org/rescode.html> could return the "primary result code" name.
> * an HRESULT <https://en.wikipedia.org/wiki/HRESULT> wrapper could return the FACILITY name.
> Would a varying domain affect the registered setUserInfoValueProvider(forDomain:provider:) callback?

‘errorDomain’ must not vary, because it effectively identifies the Swift type.

In fact, it should be ‘static’. I’ll fix that, thanks!

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160705/d331f2d4/attachment.html>