<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Dec 21, 2015, at 5:36 PM, Colin Cornaby <<a href="mailto:colin.cornaby@mac.com" class="">colin.cornaby@mac.com</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">So here’s my 2 cents. I talked to Charles about this off list, so I’ll just say my piece and then move along. :)</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">It seems to me that ErrorType is very empty because it’s meant to be a placeholder in the language for whatever the native error type is on the platform. When I’m in AppKit/UIKit/OSS Swift Foundation, I’m using NSError. When I’m using C API, my ErrorType would probably be a typedef’d int. When I’m using Win32, my ErrorType is whatever Win32 error types are. If I’m using Swift with some platform/API where the error types are some sort of struct, or even a string type, those types can be made to conform to error type. It’s meant to be a shallow wrapper because it’s just a placeholder to wrap the native platform API.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I’m not sure I like going down the path of Swift actually trying to replace platform API, especially if it requires a hand bridge. Then you’re constantly extending the language to bridge the error types from all the different platforms. My view is that OSS Swift Foundation provides a template where the platform API cannot be assumed, and that OSS Swift Foundation defines it’s own concrete error type in NSError/Error. Certainly NSError isn’t perfect and the conversation on how to make it better is worthwhile (especially now that NSError is part of Swift Foundation, and changes could also be adopted by Obj-C Foundation where relevant.)</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">A year ago my opinion on this was very different, and I was bothering people on the Swift team for a similar improvement based on where Swift was at the time. But with OSS Foundation and multiplatform Swift my feeling has changed. I’m not comfortable with trying to promote NSError concepts higher into the language when I think Swift conforming to the host platform’s error API is the better path. My assumption is that Swift is not meant to be a platform in itself (like Java), but just a language over an existing platform.</div></div></blockquote></div><br class=""><div class="">And my two cents is:</div><div class=""><br class=""></div><div class="">NSError is antiquated, and enums conforming to ErrorType, with associated types on the case values, are much better. They are cleaner, they are easier to use, and they are nicer to look at.</div><div class=""><br class=""></div><div class="">Creating them is nicer:</div><div class=""><br class=""></div><div class="">let error = MyError.FileNotFound(url: someURL)</div><div class=""><br class=""></div><div class="">vs.</div><div class=""><br class=""></div><div class="">var userInfo: [String : AnyObject] = [NSLocalizedFailureReason : “The file \(someURL.lastPathComponent ?? “(null)”) could not be found.”, NSURLErrorKey : someURL]</div><div class="">if someURL.fileURL, let path = someURL.path { userInfo[NSFilePathErrorKey] = path }</div><div class="">let error = NSError(domain: “SomeArbitraryString”, code: Int(ErrorCodeEnum.FileNotFound.rawValue), userInfo: userInfo)</div><div class=""><br class=""></div><div class="">Comparing them is nicer:</div><div class=""><br class=""></div><div class="">if case let .FileNotFound(url) = error {</div><div class=""> // handle the error</div><div class="">}</div><div class=""><br class=""></div><div class="">vs.</div><div class=""><br class=""></div><div class="">if error.domain == “SomeArbitraryString” && error.code == Int(ErrorCodeEnum.FileNotFound.rawValue) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let url: NSURL</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if let theURL = error.userInfo[NSURLErrorKey] as? NSURL {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>url = theURL</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>} else if let path = error.userInfo[NSFilePathErrorKey] as? String {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>url = NSURL(fileURLWithPath: path)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>} else {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// handle not having a url, and bail out</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// now handle the error</div><div class="">}</div><div class=""><br class=""></div><div class="">I don’t think any further explanation is necessary. :-P</div><div class=""><br class=""></div><div class="">The only real problem with ErrorType is sending it to legacy AppKit APIs that expect an NSError, since there’s no way to customize what happens when the user converts one of them via “as NSError”. You have to write your own conversion method, and then be scrupulous about always calling that instead of “as NSError”, which is particularly problematic if you receive the error as a plain ErrorType without knowing that it’s your particular error type, in which case you have to do runtime type checking to see if you should use the custom conversion method or the built-in “as NSError” conversion.</div><div class=""><br class=""></div><div class="">If this could be fixed, it’d be fantastic.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>