Cevap.

Swift, Error protokolü ve throw, try, catch yapıları aracılığıyla katı bir hata yönetim sistemi destekler. Kendi hata türlerinizi tanımlamak için Error'dan miras alabilirsiniz:

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

Hata fırlatabilecek fonksiyonlar throws ile bildirilir:

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

Hatalar, do-catch bloğu ile işlenebilir:

do {
    let data = try fetchData()
    // Verilerle çalışma
} catch NetworkError.noInternet {
    print("İnternet yok")
} catch {
    print("Başka bir hata: \(error)")
}

Alternatif bir yaklaşım — Result<T, Error> tipi, sonucu veya hatayı try-catch olmadan döndürmenizi sağlar:

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

let result = fetchData()
switch result {
    case .success(let data): // Tamam
    case .failure(let err): // Hata işleme
}

Ne zaman kullanmalı:

• Eğer hata kritikse ve işlenmemesi mümkün değilse try/catch kullanın.
• Eğer fonksiyon asenkron ise veya hatayı "dışarıya" istisna olmadan iletmek kolaysa Result kullanın.

Kandırmaca soru.

Soru: "Herhangi bir türde hata fırlatıp yakalanabilir mi, örneğin, string veya sayı?"

Cevap: Hayır, Swift'te yalnızca Error protokolüne uyan türler fırlatılabilir.

// Yanlış:
throw "StringError" // Derleyici bunu yapmanıza izin vermez

// Doğru:
struct MyError: Error {}
throw MyError()

Konunun inceliklerinden habersizlikten kaynaklanan gerçek hata örnekleri.

---

Hikaye

REST API istemcisinde bir hata string olarak fırlatıyordu (throw "No data"). Kod JavaScript'te derleniyordu, ancak Swift'e çevrildiğinde kritik bir derleme hatası oluştu.

---

Hikaye

Geliştirici hatayı opsiyonel değerler aracılığıyla (return nil hatada) döndürüyordu, throw/Result yerine. Sonuç olarak, hata detayları kayboldu, bunları doğru bir şekilde işlemek zorlaştı — Sessiz hatalar oluştu.

---

Hikaye

Analiz, uygulamanın birkaç yerinde aynı hataların tek bir Error türünde gruplanmadığını gösterdi. Sonuç olarak, uygulamalar benzer arızaları farklı şekillerde işledi ve UI, tek bir hata için farklı mesajlar gösterdi — bakım ve test edilmesi zordu.