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

Erica Sadun erica at ericasadun.com
Sun Mar 6 21:10:32 CST 2016


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

-- Erica





More information about the swift-evolution mailing list