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

[Charles Kissinger]

> On Mar 6, 2016, at 7:10 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> 
>> On Mar 6, 2016, at 7:38 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>> 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.)
>> 
>> I agree. A single concrete error type with stringly-typed data inside it is the precise *opposite* of how the error mechanism should be used.
> 
> Oh dear, because that is exactly *not* what I was proposing. I was suggesting something that was a standard fallback error completely separate from any other modification to the error mechanism, just because it's extremely useful to have something to throw without having to design a full error system for things like command-line utilities, etc. In otherwords, a pre-constructed vanilla handy-error, ready for use that would have zero impact on any other error system, implementation, or mechanism.

I see. You don’t want the standard library to *use* that error type, just make it available. I still worry that including it in the standard library would be a de facto sanctioning of an error-handling anti-pattern, though (i.e., errors differentiated by string descriptions).

I certainly see the value of the context information you want to provide. It would be great if that could somehow be made available to any ErrorType.

—CK

> 
> -- Erica
> 
> 
>