<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 6, 2016, at 9:17 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><font face="Menlo" class="">NSError</font> encapsulates runtime error condition information. It uses an historic, time-tested object<div class="">built to communicate information to users and provide a basis for workarounds. </div><div class="">Swift's redesigned error mechanism differs significantly from <font face="Menlo" class="">NSError</font> in that its primary consumer</div><div class="">are API calls, via the <font face="Menlo" class="">try-catch</font> mechanism and not end-users.</div><div class=""><br class=""></div><div class="">I would not like Swift to be tied down to an archaic construct for the sake of consistency. <font face="Menlo" class="">NSError</font>'s</div><div class="">core <font face="Menlo" class="">domain/code/userInfo</font> attributes are architected to archaic use-cases. It <font face="Menlo" class="">domains</font> of</div><div class="">Mach/POSIX/Carbon/Cocoa are subsumed by Swift modules. The integer-based codes </div><div class="">can be better represented by plain-text strings, the dictionary keys model usage that </div><div class="">poorly integrates into Swift's <font face="Menlo" class="">throw-try</font> ecosystem.</div><div class=""><br class=""></div><div class="">To me, <span style="font-family: Palatino-Roman;" class="">an error should answer the following questions:</span></div><div class="" style="font-family: Palatino-Roman;"><br class=""></div><div class="" style="font-family: Palatino-Roman;">* What went wrong?</div><div class="" style="font-family: Palatino-Roman;">* Where did it go wrong?</div><div class="" style="font-family: Palatino-Roman;">* What other information am I passing along about the circumstances of the error?</div><div class="" style="font-family: Palatino-Roman;"><br class=""></div><div class="" style="font-family: Palatino-Roman;">A universal standard library error could be as simple as </div><div class="" style="font-family: Palatino-Roman;"><br class=""></div><div class=""><div class=""><font face="Menlo" class="">struct Error: ErrorType {</font></div><div class=""><font face="Menlo" class=""> let reason: String</font></div><div class=""><font face="Menlo" class="">}</font></div></div></div></div></blockquote><div><br class=""></div><div>Erica,</div><div><br class=""></div><div>I wouldn’t want a single, universal error type for the standard library. I would want to be able to selectively catch errors based on their type rather than having to look into the “reason” string to determine what happened. (In other words, the reason should be encoded in the error type.)</div><div><br class=""></div><div>Would your idea work better as a “StandardErrorProtocol” with a default implementation for “context” that provides the source location, etc.? (I have no idea how much compiler magic that might require.)</div><div><br class=""></div>—CK</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">although, I'd far prefer to add a <font face="Menlo" class="">context</font>, using the newly updated debug literals to describe</div><div class="">exactly where the error sourced from. An <a href="http://ericasadun.com/2015/08/27/capturing-context-swiftlang/" class="">ideal context</a> would include:</div><div class=""><br class=""></div><div class="">* A source location including a fully qualified module, file name and line number, shared </div><div class=""> object (dsohandle), symbol, e.g. FooType.methodName(label1: _, label2: _) (with an optional </div><div class=""> mangled name component), and column number (although I sincerely do not understand </div><div class=""> the point of column number)</div><div class="">* An indicator of release or debug build</div><div class="">* Pre-crafted strings that combine these data into printable forms suitable for release and </div><div class=""> debug output using brief, long, and exhaustive context forms.</div><div class="">* Decomposable elements, offering both the full context story while retaining an option</div><div class=""> to access and query individual components as needed.</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">struct Error: ErrorType {</font></div><div class=""><font face="Menlo" class=""> let reason: String</font></div><div class=""><font face="Menlo" class=""> let context: ContextType</font></div><div class=""><font face="Menlo" class="">}</font></div></div><div class=""><br class=""></div><div class="">further, I'd want to implement some kind of generalizable dictionary, an infoDictionary</div><div class="">rather than a userDictionary, that describes error circumstances and possible recovery</div><div class="">selectors, without being tied to the notion that the <a href="https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorObjectsDomains/ErrorObjectsDomains.html#//apple_ref/doc/uid/TP40001806-CH202-CJBGAIBJ" class="">ultimate consumer</a> is an NSAlert</div><div class="">presented to a user.</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><font face="Menlo" class="">struct Error: ErrorType {</font></div><div class=""><font face="Menlo" class=""> let reason: String</font></div><div class=""><font face="Menlo" class=""> let context: ContextType</font></div><div class=""><font face="Menlo" class=""> let infoDictionary: Dictionary<String: Any></font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div></div></div><div class="">-- Erica</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>