326 votes

Comment fournir une description localisée avec un type d'erreur en Swift ?

Je suis en train de définir un type d'erreur personnalisé avec la syntaxe Swift 3 et je veux fournir une description conviviale de l'erreur qui est renvoyée par la fonction localizedDescription de l Error objet. Comment puis-je le faire ?

public enum MyError: Error {
  case customError

  var localizedDescription: String {
    switch self {
    case .customError:
      return NSLocalizedString("A user-friendly description of the error.", comment: "My error")
    }
  }
}

let error: Error = MyError.customError
error.localizedDescription
// "The operation couldn’t be completed. (MyError error 0.)"

Y a-t-il un moyen pour que le localizedDescription pour renvoyer ma description d'erreur personnalisée ("Une description conviviale de l'erreur.") ? Notez que l'objet d'erreur ici est de type Error et non MyError . Je peux, bien sûr, transformer l'objet en MyError.

(error as? MyError)?.localizedDescription

mais y a-t-il un moyen de le faire fonctionner sans faire un casting vers mon type d'erreur ?

585voto

Martin R Points 105727

Comme décrit dans les notes de publication de Xcode 8 beta 6,

Les types d'erreurs définis par Swift peuvent fournir des descriptions d'erreurs localisées en adoptant le nouveau protocole LocalizedError.

Dans votre cas :

public enum MyError: Error {
    case customError
}

extension MyError: LocalizedError {
    public var errorDescription: String? {
        switch self {
        case .customError:
            return NSLocalizedString("A user-friendly description of the error.", comment: "My error")
        }
    }
}

let error: Error = MyError.customError
print(error.localizedDescription) // A user-friendly description of the error.

Vous pouvez fournir encore plus d'informations si l'erreur est convertie en NSError (ce qui est toujours possible) :

extension MyError : LocalizedError {
    public var errorDescription: String? {
        switch self {
        case .customError:
            return NSLocalizedString("I failed.", comment: "")
        }
    }
    public var failureReason: String? {
        switch self {
        case .customError:
            return NSLocalizedString("I don't know why.", comment: "")
        }
    }
    public var recoverySuggestion: String? {
        switch self {
        case .customError:
            return NSLocalizedString("Switch it off and on again.", comment: "")
        }
    }
}

let error = MyError.customError as NSError
print(error.localizedDescription)        // I failed.
print(error.localizedFailureReason)      // Optional("I don\'t know why.")
print(error.localizedRecoverySuggestion) // Optional("Switch it off and on again.")

En adoptant le CustomNSError protocole l'erreur peut fournir a userInfo (et aussi un dictionnaire domain y code ). Exemple :

extension MyError: CustomNSError {

    public static var errorDomain: String {
        return "myDomain"
    }

    public var errorCode: Int {
        switch self {
        case .customError:
            return 999
        }
    }

    public var errorUserInfo: [String : Any] {
        switch self {
        case .customError:
            return [ "line": 13]
        }
    }
}

let error = MyError.customError as NSError

if let line = error.userInfo["line"] as? Int {
    print("Error in line", line) // Error in line 13
}

print(error.code) // 999
print(error.domain) // myDomain

13 votes

Y a-t-il une raison pour laquelle vous faites MyError un Error d'abord et l'étendre avec LocalizedError plus tard ? Y a-t-il une différence si vous en faites un LocalizedError en premier lieu ?

14 votes

@Gee.E : Cela ne fait aucune différence. C'est juste une façon d'organiser le code (une extension pour chaque protocole). Comparez stackoverflow.com/questions/36263892/ , stackoverflow.com/questions/40502086/ ou natashatherobot.com/using-swift-extensions .

4 votes

Ah, vérifie. Je comprends ce que vous dites maintenant. La section "Conformité du protocole" sur natashatherobot.com/using-swift-extensions est en effet un bon exemple de ce que vous voulez dire. Merci !

63voto

Reza Shirazian Points 1465

J'ajouterais également, si votre erreur a des paramètres comme ceci

enum NetworkError: LocalizedError {
  case responseStatusError(status: Int, message: String)
}

vous pouvez appeler ces paramètres dans votre description localisée comme ceci :

extension NetworkError {
  public var errorDescription: String? {
    switch self {
    case .responseStatusError(status: let status, message: let message):
      return "Error with status \(status) and message \(message) was thrown"
  }
}

Vous pouvez même faire plus court comme ceci :

extension NetworkError {
  public var errorDescription: String? {
    switch self {
    case let .responseStatusError(status, message):
      return "Error with status \(status) and message \(message) was thrown"
  }
}

11voto

matt Points 60113

Il existe désormais deux protocoles d'adoption d'erreur que votre type d'erreur peut adopter afin de fournir des informations supplémentaires à Objective-C : LocalizedError et CustomNSError. Voici un exemple d'erreur qui les adopte tous les deux :

enum MyBetterError : CustomNSError, LocalizedError {
    case oops

    // domain
    static var errorDomain : String { return "MyDomain" }
    // code
    var errorCode : Int { return -666 }
    // userInfo
    var errorUserInfo: [String : Any] { return ["Hey":"Ho"] };

    // localizedDescription
    var errorDescription: String? { return "This sucks" }
    // localizedFailureReason
    var failureReason: String? { return "Because it sucks" }
    // localizedRecoverySuggestion
    var recoverySuggestion: String? { return "Give up" }

}

3 votes

Pouvez-vous faire un montage ? Vos exemples n'aident pas beaucoup à comprendre la valeur de chacun. Ou supprimez-la simplement parce que la réponse de MartinR offre exactement ceci...

3voto

Zafer Sevik Points 121

L'utilisation d'une structure peut être une alternative. Un peu d'élégance avec la localisation statique :

import Foundation

struct MyError: LocalizedError, Equatable {

   private var description: String!

   init(description: String) {
       self.description = description
   }

   var errorDescription: String? {
       return description
   }

   public static func ==(lhs: MyError, rhs: MyError) -> Bool {
       return lhs.description == rhs.description
   }
}

extension MyError {

   static let noConnection = MyError(description: NSLocalizedString("No internet connection",comment: ""))
   static let requestFailed = MyError(description: NSLocalizedString("Request failed",comment: ""))
}

func throwNoConnectionError() throws {
   throw MyError.noConnection
}

do {
   try throwNoConnectionError()
}
catch let myError as MyError {
   switch myError {
   case .noConnection:
       print("noConnection: \(myError.localizedDescription)")
   case .requestFailed:
       print("requestFailed: \(myError.localizedDescription)")
   default:
      print("default: \(myError.localizedDescription)")
   }
}

2voto

Vitaliy Gozhenko Points 279

Voici une solution plus élégante :

  enum ApiError: String, LocalizedError {

    case invalidCredentials = "Invalid credentials"
    case noConnection = "No connection"

    var localizedDescription: String { return NSLocalizedString(self.rawValue, comment: "") }

  }

5 votes

Cette méthode peut être plus élégante au moment de l'exécution, mais l'étape de localisation statique ne parviendra pas à extraire ces chaînes pour les traducteurs ; vous verrez apparaître un message d'erreur "Bad entry in file – Argument is not a literal string" erreur lorsque vous exécutez exportLocalizations o genstrings pour créer votre liste de textes traduisibles.

0 votes

@savinola d'accord, la localisation statique ne fonctionnera pas dans ce cas. Peut-être faut-il utiliser switch + case est la seule option...

0 votes

L'utilisation de valeurs brutes empêchera également l'utilisation de valeurs associées pour toutes vos erreurs.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X