On Jun 29, 2016, at 10:05 AM, Dmitri Gribenko <[email protected]> wrote:

On Wed, Jun 29, 2016 at 4:13 AM, Charles Srstka
<[email protected]> wrote:
On Jun 29, 2016, at 2:50 AM, Dmitri Gribenko via swift-evolution
<[email protected]> wrote:


I'm not sure I really want '.url' and '.stringEncoding' on every
Error.  'var underlying' is universally useful, but providing it
requires a implementing conformance to CustomNSError, which has to
vend a weakly-typed dictionary.  Is this really the API we want to
expose?


We need to expose the dictionary in order to provide full compatibility with
NSError.

The full compatibility argument is universal, and it can be applied to
anything.  Not always the answer is "dump the compatibility APIs onto
the Swift type”.

Yes, that’s a reasonable point. These APIs are available by bouncing through NSError and (at worst) looking up a known key in its userInfo dictionary. I only truly care about localizedDescription being available on Error(Protocol), because that’s universal and useful. The others… I think I’ll go put them on (NS)CocoaError, which covers the Cocoa error domain and is where one might reasonably expect these keys to show up. It’s fairly easy for other, specific error types to do the same if they need them. If we truly need some of these on all error types, we can add that at a later time.

I’ll revise the proposal shortly.


Also, the underlying error has to be stored somewhere, which
effectively prevents implementers of CustomNSError from being enums.


Not at all. Your enum can implement a dynamic errorUserInfo property that
will populate the dictionary with the appropriate values. If you need to
actually store something, that can be done with enum cases as well.

You would need to store the underlying error in every enum case, which
creates boilerplate, and you'd lose the raw representable conformance.


If it’s important for the error type to store the underlying error, you can use a struct or add the payload to every enum case. Maybe some future feature will make the latter option easier (I feel like we saw a pitch about that before).

- Doug

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to