<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>I can see the benefit in having a basic error type for use with alerts and such, but arguably that's what NSError is for (although NSError doesn't pick up context info). A downside to the type you're proposing is it doesn't provide any way to programmatically indicate what went wrong (the strings are presumably for human consumption, not programmatic introspection), which makes it largely useless for anything except the point where you're about to hand off an error to the UI for display (where it's too late to gather context info).<br></div>
<div> </div>
<div>Also I disagree that the codes can be better represented as strings. Strings are presumably for human consumption, but error codes are for programmatic consumption. You don't want to do string comparisons to figure out what type of error it is. And of course codes themselves are obsoleted by having strong type information, which is what Swift already has with concrete ErrorType implementations.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
<div> </div>
<div>On Sun, Mar 6, 2016, at 09:17 AM, Erica Sadun via swift-evolution wrote:<br></div>
<blockquote type="cite"><div><span class="font" style="font-family:Menlo">NSError</span> encapsulates runtime error condition information. It uses an historic, time-tested object<br></div>
<div>built to communicate information to users and provide a basis for workarounds. <br></div>
<div>Swift's redesigned error mechanism differs significantly from <span class="font" style="font-family:Menlo">NSError</span> in that its primary consumer<br></div>
<div>are API calls, via the <span class="font" style="font-family:Menlo">try-catch</span> mechanism and not end-users.<br></div>
<div> </div>
<div>I would not like Swift to be tied down to an archaic construct for the sake of consistency. <span class="font" style="font-family:Menlo">NSError</span>'s<br></div>
<div>core <span class="font" style="font-family:Menlo">domain/code/userInfo</span> attributes are architected to archaic use-cases. It <span class="font" style="font-family:Menlo">domains</span> of<br></div>
<div>Mach/POSIX/Carbon/Cocoa are subsumed by Swift modules. The integer-based codes <br></div>
<div>can be better represented by plain-text strings, the dictionary keys model usage that <br></div>
<div>poorly integrates into Swift's <span class="font" style="font-family:Menlo">throw-try</span> ecosystem.<br></div>
<div> </div>
<div>To me, <span class="font" style="font-family:Palatino-Roman">an error should answer the following questions:</span><br></div>
<div style="font-family:Palatino-Roman;"> </div>
<div style="font-family:Palatino-Roman;">* What went wrong?<br></div>
<div style="font-family:Palatino-Roman;">* Where did it go wrong?<br></div>
<div style="font-family:Palatino-Roman;">* What other information am I passing along about the circumstances of the error?<br></div>
<div style="font-family:Palatino-Roman;"> </div>
<div style="font-family:Palatino-Roman;">A universal standard library error could be as simple as <br></div>
<div style="font-family:Palatino-Roman;"> </div>
<div><div><span class="font" style="font-family:Menlo">struct Error: ErrorType {</span><br></div>
<div><span class="font" style="font-family:Menlo"> let reason: String</span><br></div>
<div><span class="font" style="font-family:Menlo">}</span><br></div>
<div> </div>
<div>although, I'd far prefer to add a <span class="font" style="font-family:Menlo">context</span>, using the newly updated debug literals to describe<br></div>
<div>exactly where the error sourced from. An <a href="http://ericasadun.com/2015/08/27/capturing-context-swiftlang/">ideal context</a> would include:<br></div>
<div> </div>
<div>* A source location including a fully qualified module, file name and line number, shared <br></div>
<div> object (dsohandle), symbol, e.g. FooType.methodName(label1: _, label2: _) (with an optional <br></div>
<div> mangled name component), and column number (although I sincerely do not understand <br></div>
<div> the point of column number)<br></div>
<div>* An indicator of release or debug build<br></div>
<div>* Pre-crafted strings that combine these data into printable forms suitable for release and <br></div>
<div> debug output using brief, long, and exhaustive context forms.<br></div>
<div>* Decomposable elements, offering both the full context story while retaining an option<br></div>
<div> to access and query individual components as needed.<br></div>
<div> </div>
<div><div><span class="font" style="font-family:Menlo">struct Error: ErrorType {</span><br></div>
<div><span class="font" style="font-family:Menlo"> let reason: String</span><br></div>
<div><span class="font" style="font-family:Menlo"> let context: ContextType</span><br></div>
<div><span class="font" style="font-family:Menlo">}</span><br></div>
</div>
<div> </div>
<div>further, I'd want to implement some kind of generalizable dictionary, an infoDictionary<br></div>
<div>rather than a userDictionary, that describes error circumstances and possible recovery<br></div>
<div>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">ultimate consumer</a> is an NSAlert<br></div>
<div>presented to a user.<br></div>
<div> </div>
<div><div><div><span class="font" style="font-family:Menlo">struct Error: ErrorType {</span><br></div>
<div><span class="font" style="font-family:Menlo"> let reason: String</span><br></div>
<div><span class="font" style="font-family:Menlo"> let context: ContextType</span><br></div>
<div><span class="font" style="font-family:Menlo"> let infoDictionary: Dictionary<String: Any></span><br></div>
<div><span class="font" style="font-family:Menlo">}</span><br></div>
<div> </div>
</div>
</div>
<div>-- Erica<br></div>
<div> </div>
<div> </div>
</div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div> </div>
</body>
</html>