Antwort.

Swift unterstützt ein strenges Fehlerbehandlungssystem durch das Protokoll Error und die Konstrukte throw, try, catch. Sie können eigene Fehlertypen definieren, indem Sie von Error erben:

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

Funktionen, die einen Fehler auslösen können, werden mit throws deklariert:

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

Fehler können mit einem do-catch-Block verarbeitet werden:

do {
    let data = try fetchData()
    // Arbeiten mit den Daten
} catch NetworkError.noInternet {
    print("Kein Internet")
} catch {
    print("Ein anderer Fehler: \(error)")
}

Ein alternativer Ansatz ist der Typ Result<T, Error>, der es ermöglicht, ein Ergebnis oder einen Fehler ohne try-catch zurückzugeben:

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

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

Wann verwenden:

• Verwenden Sie try/catch, wenn der Fehler kritisch ist und nicht ignoriert werden kann.
• Verwenden Sie Result, wenn die Funktion asynchron ist oder wenn es praktisch ist, den Fehler "nach außen" ohne Ausnahmen weiterzugeben.

Fangfrage.

Frage: "Kann man Fehler beliebigen Typs auslösen und abfangen, zum Beispiel Strings oder Zahlen?"

Antwort: Nein, in Swift können nur Typen, die dem Protokoll Error entsprechen, ausgelöst werden.

// Falsch:
throw "StringError" // Der Compiler erlaubt das nicht

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

Beispiele realer Fehler aufgrund von Unkenntnis der Feinheiten des Themas.

---

Geschichte

Im Projekt REST API warf der Client einen Fehler als String (throw "No data"). Der Code wurde in JavaScript kompiliert, aber nach der Übersetzung nach Swift trat ein fataler Kompilierungsfehler auf.

---

Geschichte

Der Entwickler gab den Fehler über optionale Werte zurück (return nil bei einem Fehler), anstatt über throw/Result. Dadurch gingen die Fehlerdetails verloren, und es war schwierig, sie korrekt zu behandeln – Silent Fails traten auf.

---

Geschichte

Die Analyse zeigte, dass an mehreren Stellen der Anwendung identische Fehler nicht in einen einzigen Typ Error gruppiert waren. Infolgedessen wurden ähnliche Ausfälle in der Anwendung unterschiedlich behandelt, und die UI zeigte unterschiedliche Nachrichten für denselben Fehler – schwer zu pflegen und zu testen.