Rust'ta Java veya C++ gibi geleneksel istisnalar (exceptions) yoktur; bunun yerine hata döndürmek için Result ve Option sarmalayıcı türleri kullanılır.
Result<T, E> — ya bir değer (Ok(T)) ya da bir hata (Err(E)) içerir. Genellikle, düzgün bir şekilde tamamlanmayabilecek işlemler için (örneğin, dosya girişi-çıkışı) kullanılır.
Option<T> — isteğe bağlı değerler için: ya Some(T) ya da None, hata hakkında bilgi olmadan. Örnek:
fn divide(x: f64, y: f64) -> Option<f64> { if y == 0.0 { None } else { Some(x / y) } }
Rust'ta try/catch tarzı istisnalar yoktur; bu, hataların şeffaf, kontrol edilebilir bir akışını sağlamak ve istisnaları sürdürmek için çöp toplayıcı veya unwind motoruna ihtiyaç duymamak içindir.
Neden panic! normal hata işleme için kullanılamaz?
Cevap: panic!, yürütme akışını sonlandırır, geri dönme fırsatı vermez, unwinding/abort'a neden olur. Ancak hatalar Result ile döndürüldüğünde, çağıran taraf bunları işleyebilir. Örnek:
fn foo() -> Result<(), String> { Err("Bir şeylerin yanlış gittiği".to_string()) } // yerine fn foo() { panic!("Bir şeylerin yanlış gittiği"); }
Hikaye
Görüntü işleme mikro hizmetinde, geliştirici tüm anormal durumları ele almak için
panic!kullandı. Bu, herhangi bir hata durumunda hizmetin acil olarak kapanmasına neden oldu, bunun yerine müşteri ile hata ayrıntılarıyla birlikte düzgün bir HTTP yanıtı döndürmeyi başaramadı.
Hikaye
Bir CLI aracı içinde, mümkün olan tüm giriş-çıkışlar için
unwrap()kullanıldı, olası hatalar işlenmedi. Sonuç olarak, dosya sistemi hatası durumunda program, herhangi bir mesaj veya teşhis olmaksızın sonlandı.
Hikaye
Bir analiz hizmetinde, her küçük hata için Option kullanmaya çalıştılar ve bu hata bilgilerini kaybetmelerine ve hata ayıklamayı zorlaştırmalarına yol açtı. Hata enumları ile Result'a geçtikten sonra, hataları bulması ve düzeltmesi daha kolay oldu.