[swift-evolution] [Proposal draft] NSError bridging

Dmitri Gribenko gribozavr at gmail.com
Wed Jun 29 02:50:22 CDT 2016


On Mon, Jun 27, 2016 at 11:17 AM, Douglas Gregor via swift-evolution
<swift-evolution at swift.org> wrote:
> extension ErrorProtocol {
>   // Note: for exposition only. Not actual API.
>   private var userInfo: [NSObject : AnyObject] {
>     return (self as! NSError).userInfo
>   }
>
>   var localizedDescription: String {
>     return (self as! NSError).localizedDescription
>   }
>
>   var filePath: String? {
>     return userInfo[NSFilePathErrorKey] as? String
>   }
>
>   var stringEncoding: String.Encoding? {
>     return (userInfo[NSStringEncodingErrorKey] as? NSNumber)
>              .map { String.Encoding(rawValue: $0.uintValue) }
>   }
>
>   var underlying: ErrorProtocol? {
>     return (userInfo[NSUnderlyingErrorKey] as? NSError)?.asError
>   }
>
>   var url: URL? {
>     return userInfo[NSURLErrorKey] as? URL
>   }
> }

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?

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

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/


More information about the swift-evolution mailing list