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

[Jon Shier]

> 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 )
> }
> ```
> 
> I would go so far as to say that generic errors are an anti-pattern in Swift.

	I wouldn’t call them an anti pattern, but they do force the user to make a decision about how they’re handling errors. Either everything is wrapped in their own custom error type at some point, or they just return NSErrors for everything. I preferred wrapping everything in my own type so handling was centralized and I knew my code exhaustively handled all cases. Of course I never used to the more advanced features of NSError. It certainly looks like this has to change now.

> On Aug 14, 2016, at 9:43 PM, Charles Srstka <cocoadev at 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.


Thanks everyone,

Jon