> On Mar 16, 2017, at 4:18 PM, Itai Ferber <[email protected]> wrote: > > Foundation’s common currency type for errors is unequivocally NSError, and > we’re not looking to change that as part of this proposal. > Not in Swift, where it’s unequivocally Error, and errors thrown from Foundation bridge to CocoaError. Types that conform to Error can have custom bridges both to and from NSError. I didn’t suggest breaking up Foundation’s error types as part of this proposal, merely that while all this new code is being written, it’s a little backwards to tack on new home-brewed error codes to NSCocoaErrorDomain that don’t even exist in Objective-C. > Reusing errors from the Cocoa domain has always been a reasonable choice for > 3rd-party developers, and we’d like to keep doing this. > > We are looking to improve the experience of throwing such errors (with some > trivial extensions) by allowing you to do something like throw > CocoaError.error(.coderInvalidValue). (Of course, don’t quote me on the exact > syntax, as this is totally subject to change.) > This is pretty simple, and nets you free user-facing localization. > But, again, none of the three advantages mentioned here are exclusive to errors vended through NSError.
Zach Waldowski [email protected] > On 15 Mar 2017, at 22:46, Zach Waldowski wrote: > > > Just a little one that came up with when thinking over the companion > proposal… see inline. > >> On Mar 15, 2017, at 6:43 PM, Itai Ferber via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> Foundation-Provided Errors >> >> Along with providing the above encoders and decoders, we would like to >> promote the use of a common set of error codes and messages across all new >> encoders and decoders. A common vocabulary of expected errors allows >> end-users to write code agnostic about the specific encoder/decoder >> implementation they are working with, whether first-party or third-party: >> >> extension CocoaError.Code { >> public static var coderInvalidValue: CocoaError.Code >> public static var coderTypeMismatch: CocoaError.Code >> public static var coderReadCorrupt: CocoaError.Code >> public static var coderValueNotFound: CocoaError.Code >> } > > I find all the reasons compelling, but I don’t with the overall choice. A > common vocabulary, side table info, and localization can be achieved with a > dedicated error type for coders. I understand ABI (sorta) concerns are > involved here, that older Foundations will continue to return the same > NSError codes. However, it's never felt appropriate to create my own error > instances with NSCocoaErrorDomain, and this feels very similar to that. What > are our options here? > > Zach Waldowski > [email protected] <mailto:[email protected]> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
