Antwoord.

Swift ondersteunt een strikte foutafhandelingsysteem via het protocol Error en de constructies throw, try, catch. Je kunt je eigen fouttypes definiëren door van Error te erven:

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

Functies die een fout kunnen throwen worden verklaard met throws:

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

Fouten kunnen worden verwerkt met een do-catch-blok:

do {
    let data = try fetchData()
    // Werken met gegevens
} catch NetworkError.noInternet {
    print("Geen internet")
} catch {
    print("Andere fout: \(error)")
}

Een alternatieve benadering is het type Result<T, Error>, waarmee je het resultaat of een fout kunt retourneren zonder try-catch:

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

let result = fetchData()
switch result {
    case .success(let data): // OK
    case .failure(let err): // Foutafhandeling
}

Wanneer te gebruiken:

• Gebruik try/catch als de fout kritiek is en niet genegeerd kan worden.
• Gebruik Result als de functie asynchroon is, of wanneer het handig is om de fout "buiten" door te geven zonder uitzonderingen.

Vragen met een val.

Vraag: "Kun je fouten van elk type throwen en vangen, bijvoorbeeld strings of getallen?"

Antwoord: Nee, in Swift kun je alleen typen throwen die voldoen aan het protocol Error.

// Onjuist:
throw "StringError" // De compiler staat dit niet toe

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

Voorbeelden van echte fouten door gebrek aan kennis over het onderwerp.

---

Verhaal

In een REST API-clientproject gooide een fout een string (throw "No data"). De code compileerde in JavaScript, maar na het vertalen naar Swift ontstond er een fatale compileerfout.

---

Verhaal

Een ontwikkelaar retourneerde een fout via optionele waarden (return nil bij een fout), in plaats van via throw/Result. Als gevolg daarvan gingen foutdetails verloren, was het moeilijk om deze correct te verwerken — er deden zich stille fouten voor.

---

Verhaal

Analyse toonde aan dat op verschillende plaatsen in de applicatie dezelfde fouten niet waren gegroepeerd in één type Error. Daardoor verwerkten applicaties op verschillende manieren soortgelijke fouten, en de UI toonde verschillende berichten voor dezelfde fout — moeilijk te onderhouden en te testen.