[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