Réponse.

Swift prend en charge un système strict de gestion des erreurs via le protocole Error et les constructions throw, try, catch. Vous pouvez définir vos propres types d'erreurs en héritant de Error :

enum NetworkError: Error {
    case noInternet
    case serverError(code: Int)
    case unknown
}

Les fonctions pouvant lancer une erreur sont déclarées avec throws :

func fetchData() throws -> Data {
    // ...
    throw NetworkError.noInternet
}

Les erreurs peuvent être gérées à l'aide d'un bloc do-catch :

do {
    let data = try fetchData()
    // Traitement des données
} catch NetworkError.noInternet {
    print("Pas d'internet")
} catch {
    print("Une autre erreur : \(error)")
}

Une approche alternative consiste à utiliser le type Result<T, Error>, qui permet de retourner soit un résultat soit une erreur sans avoir besoin de try-catch :

func fetchData() -> Result<Data, NetworkError> {
    // ...
    return .failure(.noInternet)
}

let result = fetchData()
switch result {
    case .success(let data): // OK
    case .failure(let err): // Gestion de l'erreur
}

Quand utiliser :

• Utilisez try/catch si l'erreur est critique et doit être gérée.
• Utilisez Result si la fonction est asynchrone, ou lorsque vous préférez transmettre l'erreur "vers l'extérieur" sans exceptions.

Question piégeuse.

Question : "Peut-on lancer et attraper des erreurs de n'importe quel type, comme des chaînes ou des nombres ?"

Réponse : Non, en Swift, seules les types conformes au protocole Error peuvent être lancés.

// Incorrect :
throw "StringError" // Le compilateur ne permettra pas cela

// Correct :
struct MyError: Error {}
throw MyError()

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.

---

Histoire

Dans un projet client REST API, l'erreur était lancée sous forme de chaîne (throw "No data"). Le code compilait en JavaScript, mais après la conversion en Swift, une erreur de compilation fatale est survenue.

---

Histoire

Un développeur retournait une erreur via des valeurs optionnelles (return nil en cas d'erreur), plutôt que par throw/Result. En conséquence, les détails des erreurs étaient perdus, ce qui compliquait leur traitement correct — des échecs silencieux survenaient.

---

Histoire

L'analyse a montré qu'à plusieurs endroits de l'application, des erreurs similaires n'avaient pas été regroupées sous un seul type Error. En fin de compte, les applications traitaient de manière différente des défaillances de même type, l'UI affichait des messages différents pour une même erreur — difficile à maintenir et à tester.