> On Aug 15, 2016, at 12:12 AM, Jon Shier <j...@jonshier.com> wrote: > >> On Aug 14, 2016, at 9:43 PM, Charles Srstka <cocoa...@charlessoft.com >> <mailto:cocoa...@charlessoft.com>> wrote: >> >> Is there something wrong with just returning a Swift.Error and using casting >> to catch specific errors? > > Fundamentally, I think there is, as it requires users know every type > of error that could possibly be returned by an API to handle them > exhaustively, or for users to create some sort of default behavior that may > not be optimal or safe in all cases. Unfortunately I understand now that it’s > largely unavoidable given the nature of NSError and error handling in Apple’s > frameworks in general. So I’ve accepted that’s how we have to do it from now > on. My recent questions, however, were merely seeking guidance as a framework > developer. I’ve come to the conclusion that there isn’t really a better > solution for Alamofire than removing the generic error parameter from the > relevant types and letting Error bubble up from the underlying frameworks. > Users can still wrap everything in a custom type that captures the underlying > errors or handle everything manually. I guess there is no clever solution > here.
Why do you need to exhaustively handle every type of error that could occur? Don’t you only need to know about the small subset of errors that you know you can recover from, and for the rest, bail and pass the error on down the chain to whatever ultimately ends up presenting the error? Charles
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
