<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>NSError' domains and code create a universal mechanism to filter errors from logs by semantic grouping. Your new proposed type lacks this fairly important quality. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Is the intent that the reason string to be presented to the user? If so, that's not a great story for localization.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">As for context, release vs debug is not a sufficient breakdown. A lot of software is built with much more granularity that just those two options. Such information included build numbers, branching, flags to light up experimental features, etc... </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">As for column number, you'll be happy to have it for the cases you have two throwing calls on the same line. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">-David<br><br>Sent from my iPhone</div><div><br>On Mar 6, 2016, at 9:17 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><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></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>