Вы можете создать протокол, соответствующий протоколу Swift LocalizedError, со следующими значениями:

protocol OurErrorProtocol: LocalizedError {

    var title: String? { get }
    var code: Int { get }
}

Это позволяет нам создавать конкретные ошибки, такие как:

struct CustomError: OurErrorProtocol {

    var title: String?
    var code: Int
    var errorDescription: String? { return _description }
    var failureReason: String? { return _description }

    private var _description: String

    init(title: String?, description: String, code: Int) {
        self.title = title ?? "Error"
        self._description = description
        self.code = code
    }
}

Вы можете создавать перечисления для работы с ошибками:)

enum RikhError: Error {
    case unknownError
    case connectionError
    case invalidCredentials
    case invalidRequest
    case notFound
    case invalidResponse
    case serverError
    case serverUnavailable
    case timeOut
    case unsuppotedURL
 }

И затем создайте метод внутри enum, чтобы получить код ответа http и вернуть соответствующую ошибку в return:)

static func checkErrorCode(_ errorCode: Int) -> RikhError {
        switch errorCode {
        case 400:
            return .invalidRequest
        case 401:
            return .invalidCredentials
        case 404:
            return .notFound
        //bla bla bla
        default:
            return .unknownError
        }
    }

Наконец обновите свой блок сбоев, чтобы принять один параметр типа RikhError:)

У меня есть подробное руководство о том, как реструктурировать традиционную объектно-ориентированную сетевую модель на основе Objective-C в современную протокольно-ориентированную модель с использованием Swift3 здесь https://learnwithmehere.blogspot.in посмотрите :)

Надеюсь, это поможет :)

Следует использовать объект NSError.

let error = NSError(domain:"", code:401, userInfo:[ NSLocalizedDescriptionKey: "Invaild access token"])

Затем приведите NSError к объекту Error

Реализовать LocalizedError:

struct StringError : LocalizedError
{
    var errorDescription: String? { return mMsg }
    var failureReason: String? { return mMsg }
    var recoverySuggestion: String? { return "" }
    var helpAnchor: String? { return "" }

    private var mMsg : String

    init(_ description: String)
    {
        mMsg = description
    }
}

Обратите внимание, что простая реализация ошибки, например, как описано в одном из ответов, завершится неудачей (по крайней мере, в Swift 3), а вызов localizedDescription приведет к строке "операция не может быть завершена. (.Ошибка StringError 1.) "

Я знаю, что вы уже удовлетворились ответом, но если вам интересно знать правильный подход, то это может быть полезно для вас. Я бы предпочел не смешивать код ошибки http-ответа с кодом ошибки в объекте error (запутался? пожалуйста, продолжайте читать немного...).

Коды ответа http являются стандартными кодами ошибок об ответе http, определяющими общие ситуации, когда ответ получен и изменяется от 1xx до 5xx ( например, 200 OK, 408 запрос тайм-аут, 504 шлюз timeout etc - http://www.restapitutorial.com/httpstatuscodes.html )

Код ошибки в объекте NSError обеспечивает очень специфическую идентификацию вида ошибки, описываемой объектом для конкретной области приложения / продукта / программного обеспечения. Например, ваше приложение может использовать 1000 для "Извините, вы не можете обновить эту запись более одного раза в день" или сказать 1001 для "вам нужна роль менеджера для доступа к этому ресурсу"... которые специфичны для вашего домена / приложения логика.

Для очень небольшого приложения иногда эти два понятия объединяются. Но они совершенно разные, как вы можете видеть, и очень важны и полезны для проектирования и работы с большим программным обеспечением.

Таким образом, для лучшей обработки кода можно использовать два метода:

1. Обратный вызов завершения выполнит все проверки

completionHandler(data, httpResponse, responseError) 

2. Ваш метод решает ситуацию успеха и ошибки, а затем вызывает соответствующий обратный вызов

if nil == responseError { 
   successCallback(data)
} else {
   failureCallback(data, responseError) // failure can have data also for standard REST request/response APIs
}

Счастливое кодирование :)