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

[Erica Sadun]

The source context is super-handy. ("File "foo.swift", line 23: "Bad moon tonight"").

I included all the other stuff more or less as a mental cut-and-paste from the discussion 
about how the error constants still needed to evolve (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md>)

And I threw in a dictionary because who doesn't love a dictionary?

But yeah, GenericError, BasicError, SimpleError, anything like that. And you know half the time people are just going to "guard try? blah else {fatalError("oops")}"

-- E


> On Mar 6, 2016, at 8:47 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> 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.
> 
> Ah.
> 
> If that's what you have in mind, I would give it a name like SimpleError, GenericError, or UnspecifiedError, and I would not have it carry any state other than an error message (if we introduce some standard mechanism to convey an error message, like using CustomStringConvertible). I think that, at the point where you need to pack a generic error full of random information or figure out where in the source code it came from, you probably need to start explicitly modeling the errors your code can generate.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160306/df242882/attachment.html>