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

[Erica Sadun]

My primary consumer is the developer and does not exclude use of NSError or traditional Cocoa pathways.

-- E

> On Mar 6, 2016, at 12:32 PM, David Owens II <david at owensd.io> wrote:
> 
> 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. 
> 
> Is the intent that the reason string to be presented to the user? If so, that's not a great story for localization.
> 
> 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... 
> 
> As for column number, you'll be happy to have it for the cases you have two throwing calls on the same line. 
> 
> -David
> 
> Sent from my iPhone
> 
> On Mar 6, 2016, at 9:17 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto: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
>> }
>> 
>> 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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/623f635a/attachment.html>