> On May 2, 2016, at 5:45 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > >> On May 2, 2016, at 4:48 PM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org> wrote: >>>> NSError bridging can also be extracted from the runtime, and the same >>>> functionality exposed as a factory initializer on NSError: >>>> >>> I think that this proposal is overall really great, but what does it do to >>> the “catch let x as NSError” pattern? What is the replacement? If the >>> result is ugly, we may have to subset out NSError out of this pass, and >>> handle it specifically with improvements to the error bridging story. >> >> Grant me the serenity to accept the `NSError` I cannot change and the >> courage to change the bridging conversions I should. Grant me the wisdom to >> know the difference between a partial solution that offers a cleaner more >> predictable interface set now and a full solution that cannot be achieved in >> a reasonable timeframe. >> >> -- E > > Among the things that Billy Pilgrim could not change were the past, the > present, and the future. Hopefully we have better luck, because the ErrorType > to NSError bridging is currently a bit buggy. > > Have a look at this code, and take a guess at what the results should be: > > import Foundation > > extension ErrorType { > public func toNSError() -> NSError { > return self as NSError > } > } > > let error = NSError(domain: "Foo", code: -1, userInfo: > [NSLocalizedFailureReasonErrorKey : "Something went wrong"]) > > let ns = error.toNSError() > > print("Type of error was \(error.dynamicType), type of ns is > \(ns.dynamicType)") > > print("error's user info: \(error.userInfo)") > print("ns user info: \(ns.userInfo)”) > > -- > > The results are a bit surprising: > > Type of error was NSError, type of ns is _SwiftNativeNSError > error's user info: [NSLocalizedFailureReason: Something went wrong] > ns user info: [:] > > What happened was: > > 1. The toNSError() method showed up for our NSError, since NSError is > presented to Swift as conforming to ErrorType. > > 2. However, due to a lack of dynamism, the code in the extension assumes that > we have a Swift native error and *not* an NSError, so it goes ahead and wraps > the NSError inside another NSError. > > 3. And since Swift doesn’t currently do anything to address the userInfo > field, the userInfo that our error had gets chopped off. > > Whoops.
This is a known bug, not intended behavior. The runtime rewraps NSErrors in a bridging _SwiftNativeNSError when it should just pass them through. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution