> On Jul 5, 2016, at 5:00 PM, Ben Rimmington <m...@benrimmington.com> wrote:
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md>
>
> The new protocols could be combined into a single CustomNSError protocol.
> This would mirror the NSError class APIs, which are being customized.
Why is that good? The two primary protocols—LocalizedError and
RecoverableError—provide a more focused, easy-to-understand experience for
opting in to specific behavior. CustomNSError is a fallback for “I want to do
something special with the generated NSError”.
>
> Instead of using NSError.setUserInfoValueProvider(forDomain:provider:)
> could you wrap the CustomNSError value inside an NSError subclass?
>
> class _CustomNSError: NSError {
>
> private let _error: CustomNSError
>
> init(_error: CustomNSError) {
> self._error = _error
> super.init(
> domain: _error.dynamicType.errorDomain,
> code: _error.errorCode,
> userInfo: _error.errorUserInfo)
> }
>
> override var localizedDescription: String {
> return _error.errorDescription ?? super.localizedDescription
> }
>
> override var localizedFailureReason: String? {
> return _error.failureReason ?? super.localizedFailureReason
> }
>
> override var localizedRecoverySuggestion: String? {
> return _error.recoverySuggestion ??
> super.localizedRecoverySuggestion
> }
>
> override var localizedRecoveryOptions: [String]? {
> return _error.recoveryOptions ?? super.localizedRecoveryOptions
> }
>
> override var recoveryAttempter: AnyObject? {
> if _error.recoveryOptions != nil {
> return _NSErrorRecoveryAttempter(error: _error)
> } else {
> return super.recoveryAttempter
> }
> }
>
> override var helpAnchor: String? {
> return _error.helpAnchor ?? super.helpAnchor
> }
> }
We could, but why? This is precisely what user-info value providers were
designed for.
- Doug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
