[swift-evolution] [Discussion] Adopting a new common error type outside the bounds of NSError

[Charles Kissinger]

> On Mar 6, 2016, at 9:17 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> NSError encapsulates runtime error condition information. It uses an historic, time-tested object
> built to communicate information to users and provide a basis for workarounds. 
> Swift's redesigned error mechanism differs significantly from NSError in that its primary consumer
> are API calls, via the try-catch mechanism and not end-users.
> 
> I would not like Swift to be tied down to an archaic construct for the sake of consistency. NSError's
> core domain/code/userInfo attributes are architected to archaic use-cases. It domains of
> Mach/POSIX/Carbon/Cocoa are subsumed by Swift modules. The integer-based codes 
> can be better represented by plain-text strings, the dictionary keys model usage that 
> poorly integrates into Swift's throw-try ecosystem.
> 
> To me, an error should answer the following questions:
> 
> * What went wrong?
> * Where did it go wrong?
> * What other information am I passing along about the circumstances of the error?
> 
> A universal standard library error could be as simple as 
> 
> struct Error: ErrorType {
>   let reason: String
> }

Erica,

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.)

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.)

—CK

> although, I'd far prefer to add a context, using the newly updated debug literals to describe
> exactly where the error sourced from. An ideal context <http://ericasadun.com/2015/08/27/capturing-context-swiftlang/> would include:
> 
> * A source location including a fully qualified module, file name and line number, shared 
>   object (dsohandle), symbol, e.g. FooType.methodName(label1: _, label2: _) (with an optional 
>   mangled name component), and column number (although I sincerely do not understand 
>    the point of column number)
> * An indicator of release or debug build
> * Pre-crafted strings that combine these data into printable forms suitable for release and 
>   debug output using brief, long, and exhaustive context forms.
> * Decomposable elements, offering both the full context story while retaining an option
>   to access and query individual components as needed.
> 
> struct Error: ErrorType {
>   let reason: String
>   let context: ContextType
> }
> 
> further, I'd want to implement some kind of generalizable dictionary, an infoDictionary
> rather than a userDictionary, that describes error circumstances and possible recovery
> selectors, without being tied to the notion that the ultimate consumer <https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorObjectsDomains/ErrorObjectsDomains.html#//apple_ref/doc/uid/TP40001806-CH202-CJBGAIBJ> is an NSAlert
> presented to a user.
> 
> struct Error: ErrorType {
>   let reason: String
>   let context: ContextType
>   let infoDictionary: Dictionary<String: Any>
> }
> 
> -- Erica
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160306/5fe5c692/attachment.html>