Alamofire: errorWithCode(_:failureReason:) is deprecated

[DavidGagne]

I just started getting this XCode warning tonight. Any way to resolve it?

[rafalkitta]

You can use following code:

let userInfo: Dictionary<NSObject, AnyObject> = [NSLocalizedFailureReasonErrorKey: failureReason, Error.UserInfoKeys.StatusCode: response!.statusCode]
let error = NSError(domain: Error.Domain, code: Error.Code.StatusCodeValidationFailed.rawValue, userInfo: userInfo)

BTW, I guess that functions:

static func error(domain domain: String = Error.Domain, code: Code, failureReason: String) -> NSError

and

static func error(domain domain: String = Error.Domain, code: Int, failureReason: String) -> NSError

would be public in file Source/Error.swift.

[pbenkoe]

+1 that the the two functions @rafalkitta mentioned should be public..?

[cnoon]

They were deprecated in #1166 to stop encouraging users to create their own errors with the Alamofire domain. The code the @rafalkitta posted will work, but we'd encourage you to use your own custom domain to have a clear separation between the custom errors you're creating and the ones that Alamofire creates.

The solution to fix the warnings is to stop using the errorWithCode(_:failureReason:) API and instead create your own NSError objects directly.

Cheers. 🍻

[DavidGagne]

Here's a good explanation of a fix for this warning:
http://www.swiftbyexamples.com/2016/05/12/alamofire-custom-nserror-implementation-to-avoid-using-deprecated-errorwithcode-_-failurereason/

[jshier]

@DavidGagne I'd actually recommend that developers create their own ErrorType not based on NSError, since NSError's domain and code and rather useless. Instead, an enum, as described in that article, would work well, with each case capturing whatever state it needs to to be able to present errors to the user. But the article does outline an approach that makes this change less painful.