> 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 <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.
Thanks everyone,
Jon
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
