<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="">My primary consumer is the developer and does not exclude use of NSError or traditional Cocoa pathways.<br class=""><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 6, 2016, at 12:32 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-David<br class=""><br class="">Sent from my iPhone</div><div class=""><br 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:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" 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></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>