> On Sep 8, 2016, at 3:46 AM, Tino Heth <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
