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

[Dave Abrahams]

on Mon Mar 07 2016, Charles Kissinger <swift-evolution at swift.org> wrote:

>> 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?

Please allow me to withdraw my remark; I think I may have been
experiencing a brain outage.

Thanks for your understanding.

now-back-to-our-regularly-scheduled-bikeshed-ly y'rs,
-- 
-Dave