New Error Handling #1419
New Error Handling #1419
Conversation
# Conflicts: # Source/ParameterEncoding.swift # Source/ResponseSerialization.swift # Source/SessionManager.swift
|
@cnoon One unanswered question to also consider is whether the response serialization errors should wrap the underlying decoding errors (e.g. the |
| setBodyPartError(withCode: NSURLErrorBadURL, failureReason: "The file URL is not reachable: \(fileURL)") | ||
|
|
||
| do { | ||
| let isReachable = try fileURL.checkPromisedItemIsReachable() |
|
@jshier...I'd say there's a couple open questions about the errors themselves. What to do with JSON and plist errors and also what to do with request errors. In both cases, I'm leaning towards wrapping them up in an |
| case responseValidationFailed(reason: ValidationFailureReason) | ||
| case responseSerializationFailed(reason: SerializationFailureReason) | ||
|
|
| if let error = error as? AFError, let contentType = error.responseContentType, let acceptableTypes = error.acceptableContentTypes { | ||
| XCTAssertTrue(error.isUnacceptableContentType) | ||
| XCTAssertEqual(contentType, "application/xml") | ||
| XCTAssertEqual(acceptableTypes[0], "application/octet-stream") | ||
| } else { | ||
| XCTFail("error should not be nil") | ||
| } |
There was a problem hiding this comment.
This will crash if acceptableTypes is empty. Could we get a check for the index as well as blow out the XCTFail explanation to explain the other cases where this could fail?
There was a problem hiding this comment.
I moved the acceptable type into the let statements and updated all of the failure descriptions to describe what the if statement should be unwrapping.
* Preliminary refactoring. * Refactor to use AFError. * Update inline docs in SessionDelegate. * Update AFError implementation. * Start trying to fix tests. * Update and fix tests. * Address comments. * Remove unnecessary @testable declarations. * Cleanup whitespace.
This PR refactors Alamofire's error handling to be based around a new
AFErrortype rather thanNSError, as Swift 3 has pushed the system frameworks and consumers toward usingErrorfor everything.AFErrorconsists of a few base cases with reason types for each. Convenience booleans and other properties have been added to make interacting with type easier in end use scenarios.This PR is a works in progress as the inline and separate documentation still needs to be completed and the tests need to be updated for the new error type.