> On Jul 4, 2016, at 10:15 PM, Ben Rimmington <m...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
