[swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

[Douglas Gregor]

> On Sep 8, 2016, at 3:46 AM, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> Domain, code, and user-info are useful for Cocoa interoperability but aren’t otherwise necessary in Swift, which captures that information more directly in the (concrete) error types that conform to Error.
> So the only motivation to hide _code and _domain is to discourage Objective-C-like dispatching in Swift, right?

The only reason _code and _domain exist is for Objective-C interoperability. They are not part of the Swift error model.

> For me, that would not be enough motivation to require something like "CustomNSError", but probably this isn't the opinion of the majority.

CustomNSError exists for cases where one wants to customize how a Swift error is translated into NSError. It’s for fine-grained control of something that generally shouldn’t matter to Swift developers.

> I still think Error should be a legacy-type that is only needed for interoperability… but removing the restriction that only Error-types can be thrown is additive, so I won't continue discussing this now.


FWIW, I am completely against the direction you propose, for a number of reasons:

* If we take away the Error abstraction, then the way to deal with errors in general is via Any, which erases important meaning from the static type system 
* Throwing any old type (let’s throw an Int! A closure!) makes it *very* hard to improve handling of that error type, e.g., you’re not going to be able to retroactively make Int or String conform to LocalizedError to provide a better user experience.
* There are useful extensions of the Error protocol in Foundation, e.g., the “localizedDescription” property, that one wouldn’t (and couldn’t) put onto ‘Any’. There might be more of such extensions in the future

	- Doug