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

Maybe we’re talking about two different things. I would typically want to be able to catch errors selectively by pattern matching based on their type, enum cases, etc.. I would not want to have to do a string match on the “reason” property in order to find out what the error was, as would be required with the Error struct that was proposed.

What approach are you suggesting?

—CK

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