<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body 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 class=""><br class=""></div><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></body></html>