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

[Charles Kissinger]

> On Mar 7, 2016, at 8:23 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Sun Mar 06 2016, Charles Kissinger <swift-evolution at swift.org> wrote:
> 
>> 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.)
> 
> Are you sure?  People often reflexively think they want strong static
> typing in their errors, forgetting that error handling of the
> throw/catch variety is fundamentally dynamically typed, effectively
> introspecting the error at the catch site.  Think about the use cases.

Oh, you’re thinking about a single “StandardLibraryError” enum with multiple cases to differentiate the errors? That’s not the kind of “universal error type" I was objecting to. I wasn’t making a distinction between catching by the enum type or the enum case, just not wanting to do it by string description.

—CK

> 
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution