Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 15, 2016, at 12:12 AM, Jon Shier wrote: > >> On Aug 14, 2016, at 9:43 PM, Charles Srstka > > wrote: >> >> Is there something wrong with just returning a Swift.Error and using casting >> to catch specific

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> Generic errors have caused me problems on multiple occasions.They often make > it difficult to handle and pass-through arbitrary errors. This pseudo Swift3 > code is what I have resorted to doing on some projects. > > ``` > enum MyError : Error > { > … > > case wrappedError(

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 14, 2016, at 7:04 PM, Jon Shier wrote: > > Yes, if you return a single error type it works fine. However, since > Alamofire wraps the underlying networking frameworks there’s a need to return > the errors returned from them as well, which are now returned as

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

My 2 cents: Generic errors have caused me problems on multiple occasions.They often make it difficult to handle and pass-through arbitrary errors. This pseudo Swift3 code is what I have resorted to doing on some projects. ``` enum MyError : Error { … case wrappedError( Error

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 14, 2016, at 2:34 AM, Jon Shier wrote: > > Sorry Charles, I should’ve been more specific. This isn’t about some > other type named Error being usable, but about our doubly generic Result and > other types being usable with Error as the generic error type. If

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Sorry Charles, I should’ve been more specific. This isn’t about some other type named Error being usable, but about our doubly generic Result and other types being usable with Error as the generic error type. If we have Result defined as: public enum Result {

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 14, 2016, at 1:18 AM, Jon Shier via swift-evolution > wrote: > > An immediate problem I’m seeing is the error: using 'Error' as a > concrete type conforming to protocol 'Error' is not supported, which means we > can’t use Error in our Result or

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

An immediate problem I’m seeing is the error: using 'Error' as a concrete type conforming to protocol 'Error' is not supported, which means we can’t use Error in our Result or Response types, as both the value and error types are generic there. I’m guessing we’ll have to either remove

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Doug, et. al.: Thanks for the discussion so far; I think I understand the new error model from a user’s perspective. However, now I’m looking for some guidance for framework developers. While the proposal laid out the system types would wrap imported Objective-C errors, I don’t see

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 5, 2016, at 7:36 PM, Erica Sadun wrote: > > On Aug 5, 2016, at 8:10 PM, Kevin Ballard > wrote: >> >>> >>> On Aug 5, 2016, at 5:16 PM, Erica Sadun >> > wrote: >>> >>>

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

On Aug 5, 2016, at 8:10 PM, Kevin Ballard wrote: > >> >> On Aug 5, 2016, at 5:16 PM, Erica Sadun > > wrote: >> >> >>> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 5, 2016, at 5:16 PM, Erica Sadun wrote: > > >> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution >> > wrote: >> >>> >>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 5, 2016, at 7:16 PM, Erica Sadun via swift-evolution > wrote: > > Would it kill to allow: > > let err = NSError() > err.localizedDescription = "bad things happen" > throw err > > or even > > throw NSError("Bad things happen") You can make something that

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution >> > wrote: >> >> If all you want to do is get the

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

If all you want to do is get the localized description, then you can just say `(error as NSError).localizedDescription`. -Kevin On Fri, Aug 5, 2016, at 02:59 AM, Jean-Daniel Dupas wrote: > >> Le 5 août 2016 à 05:12, Kevin Ballard via swift-evolution > evolut...@swift.org> a écrit : >> >> With

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> Le 5 août 2016 à 05:12, Kevin Ballard via swift-evolution > a écrit : > > With NSError, you must check the domain before trying to interpret the code, > or else your code is buggy and will behave incorrectly when receiving an > unexpected error. You must check

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

With NSError, you *must* check the domain before trying to interpret the code, or else your code is buggy and will behave incorrectly when receiving an unexpected error. With SE-0112, instead of checking the domain, you check if the Error can be casted to the particular error type that represents

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Doug: Thanks for indulging me so far, I think I’ve almost got it. Prior to this, using NSError, I could just look at the relevant properties of the error if I needed to see what type it was. Network errors had different codes from CloudKit errors, POSIX errors were underlying

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 2, 2016, at 2:19 PM, Jon Shier wrote: > > Thanks Doug. I missed the rename, as earlier points still referred to > ErrorProtocol. In regards to the CloudKit errors, I appreciate the strongly > typed CKError, but why not have the methods return that type

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

You're assuming that every error passed to that method is a CKError. The documentation does not claim that to be true, so it's quite plausible that you might get other errors that are simply passed through. -Kevin On Tue, Aug 2, 2016, at 02:19 PM, Jon Shier via swift-evolution wrote: > Thanks

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Thanks Doug. I missed the rename, as earlier points still referred to ErrorProtocol. In regards to the CloudKit errors, I appreciate the strongly typed CKError, but why not have the methods return that type directly? Every usage of these methods is going to require such a cast, so why

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution > wrote: > > I’m not sure where to put such feedback, but the ErrorProtocol to Error > rename that accompanied the implementation of this proposal is very, very > painful. It completely eliminates

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

It did not eliminate that ability at all. You just need to say `Swift.Error` instead of `Error` when referring to the protocol if a nested `Error` type is in scope. For example: class MyClass { enum Error: Swift.Error { case somethingWentWrong } } -Kevin Ballard On Tue, Aug 2,

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

I’m not sure where to put such feedback, but the ErrorProtocol to Error rename that accompanied the implementation of this proposal is very, very painful. It completely eliminates the very useful ability to embed an associated Error type inside other types, as those types now conflict

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Thanks for the effort on the proposal and discussion and thanks to those working in the implementation. -Shawn On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > Wow, thanks! I’m delighted that Apple found this improvement to be worth >

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Wow, thanks! I’m delighted that Apple found this improvement to be worth inclusion in Swift 3. This will truly make the language much nicer to use with the Cocoa frameworks. Thanks! Charles > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution > wrote:

[swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md The review of "SE-0112: Improved NSError Bridging" ran from June 30 ... July 4, 2016. The proposal has been *accepted*: The community and core team agree that this proposal is a huge step