<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The source context is super-handy. ("File "foo.swift", line 23: "Bad moon tonight"").</div><div class=""><br class=""></div><div class="">I included all the other stuff more or less as a mental cut-and-paste from the discussion </div><div class="">about how the error constants still needed to evolve (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md</a>)</div><div class=""><br class=""></div><div class="">And I threw in a dictionary because <i class="">who doesn't love a dictionary</i>?</div><div class=""><br class=""></div><div class="">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")}"</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 6, 2016, at 8:47 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">I was suggesting something that was a standard fallback <br class="">error completely separate from any other modification to the error mechanism, just because it's extremely useful<br class="">to have something to throw without having to design a full error system for things like command-line utilities, etc.<br class="">In otherwords, a pre-constructed vanilla handy-error, ready for use that would have zero impact on any other error<br class="">system, implementation, or mechanism.<br class=""></blockquote><br class="">Ah.<br class=""><br class="">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.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>