Yaz\u0131l\u0131m geli\u015ftirmede hatalar ka\u00e7\u0131n\u0131lmazd\u0131r ve \u00e7o\u011fu zaman sistem \u00e7\u00f6kmelerine, veri kayb\u0131na veya g\u00fcvenlik zafiyetlerine yol a\u00e7abilir. Rust programlama dili, bu yayg\u0131n sorunlara k\u00f6kten \u00e7\u00f6z\u00fcm getiren benzersiz bir hata i\u015fleme felsefesi sunar. Bu makale, Rust’\u0131n g\u00fc\u00e7l\u00fc hata i\u015fleme mekanizmalar\u0131n\u0131 derinlemesine inceleyerek nas\u0131l daha g\u00fcvenilir ve sa\u011flam yaz\u0131l\u0131m sistemleri geli\u015ftirebilece\u011finizi ad\u0131m ad\u0131m a\u00e7\u0131klayacakt\u0131r.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda yaz\u0131l\u0131m, hayat\u0131m\u0131z\u0131n her alan\u0131na n\u00fcfuz etmi\u015f durumda. Bankac\u0131l\u0131ktan sa\u011fl\u0131\u011fa, ula\u015f\u0131mdan ileti\u015fime kadar her sekt\u00f6rde yaz\u0131l\u0131mlar kritik roller \u00fcstleniyor. Ancak yaz\u0131l\u0131m geli\u015ftirme s\u00fcreci, do\u011fas\u0131 gere\u011fi hatalara a\u00e7\u0131kt\u0131r. K\u00fc\u00e7\u00fck bir mant\u0131k hatas\u0131 bile b\u00fcy\u00fck \u00f6l\u00e7ekli sistemlerde domino etkisi yaratarak ciddi sorunlara yol a\u00e7abilir. Geleneksel programlama dilleri, genellikle “null” referanslar veya istisnalar (exceptions) gibi mekanizmalarla hata y\u00f6netimi sunar. Ne var ki, bu yakla\u015f\u0131mlar genellikle derleyici taraf\u0131ndan kontrol edilmez, bu da geli\u015ftiricilerin hata durumlar\u0131n\u0131 g\u00f6zden ka\u00e7\u0131rmas\u0131na ve potansiyel runtime (\u00e7al\u0131\u015fma zaman\u0131) \u00e7\u00f6kmelerine neden olmas\u0131na zemin haz\u0131rlar.<\/p>\n
\u00d6rne\u011fin, bir sunucunun kritik bir i\u015flem s\u0131ras\u0131nda beklemedi\u011fi bir “null” de\u011ferle kar\u015f\u0131la\u015fmas\u0131, an\u0131nda sunucu \u00e7\u00f6kmesine neden olabilir. Veritaban\u0131 ba\u011flant\u0131s\u0131n\u0131n kesilmesi veya a\u011f iste\u011finin zaman a\u015f\u0131m\u0131na u\u011framas\u0131 gibi durumlar, uygun \u015fekilde ele al\u0131nmad\u0131\u011f\u0131nda uygulaman\u0131n tamamen durmas\u0131na ve kullan\u0131c\u0131lara k\u00f6t\u00fc bir deneyim sunmas\u0131na yol a\u00e7ar. Bu t\u00fcr beklenmedik \u00e7\u00f6kmeler, sadece mali kay\u0131plara de\u011fil, ayn\u0131 zamanda kullan\u0131c\u0131 g\u00fcveninin sars\u0131lmas\u0131na ve marka itibar\u0131n\u0131n zedelenmesine de neden olabilir. \u00d6zellikle g\u00fcvenlik a\u00e7\u0131s\u0131ndan kritik sistemlerde, zay\u0131f hata y\u00f6netimi siber sald\u0131r\u0131lar i\u00e7in bir a\u00e7\u0131k kap\u0131 bile b\u0131rakabilir.<\/p>\n
Peki ya bu hatalar\u0131 daha en ba\u015fta, derleme zaman\u0131nda tespit edebilseydik? \u0130\u015fte tam da bu noktada Rust’\u0131n hata i\u015fleme yakla\u015f\u0131m\u0131 devreye giriyor. Rust, derleyicinin g\u00fcc\u00fcn\u00fc kullanarak hata y\u00f6netimini zorunlu k\u0131lar. Bu sayede, geli\u015ftiricilerin potansiyel hata durumlar\u0131n\u0131 g\u00f6z ard\u0131 etmesi neredeyse imkans\u0131z hale gelir. Geleneksel dillerdeki “runtime \u00e7\u00f6kmeler” yerine, Rust’ta genellikle “derleyici hatalar\u0131” ile kar\u015f\u0131la\u015f\u0131rs\u0131n\u0131z ki bu, \u00e7ok daha erken ve g\u00fcvenli bir problem \u00e7\u00f6zme mekanizmas\u0131d\u0131r. Rust, yaz\u0131l\u0131mlar\u0131n\u0131z\u0131 daha dayan\u0131kl\u0131, \u00f6ng\u00f6r\u00fclebilir ve sonu\u00e7 olarak \u00e7ok daha g\u00fcvenilir hale getirme potansiyeline sahiptir.<\/p>\n
Rust, hata y\u00f6netimini bir se\u00e7enek olmaktan \u00e7\u0131kar\u0131p, dilin temel bir par\u00e7as\u0131 haline getirir. Bu felsefenin merkezinde, derleyicinin t\u00fcm olas\u0131 hata durumlar\u0131n\u0131 kontrol etmesini sa\u011flayan iki \u00f6zel enum t\u00fcr\u00fc yatar: Benzer \u015fekilde, Bu temel t\u00fcrlerin yan\u0131 s\u0131ra, Rust’ta kritik ve kurtar\u0131lamaz hatalar i\u00e7in Rust’ta \u00d6ncelikle, bir <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte, <\/code><\/p>\n Bu \u00f6rnekte, Rust'\u0131n hata i\u015flemedeki en pratik \u00f6zelliklerinden biri de <\/code><\/p>\n Genellikle bir uygulaman\u0131n hata durumlar\u0131, standart hata mesajlar\u0131ndan \u00e7ok daha spesifik bilgiler gerektirir. Rust, bu ihtiyac\u0131 kar\u015f\u0131lamak i\u00e7in geli\u015ftiricilere kendi \u00f6zel hata t\u00fcrlerini tan\u0131mlama ve y\u00f6netme esnekli\u011fi sunar. Bu, uygulaman\u0131z\u0131n ba\u011flam\u0131na \u00f6zg\u00fc anlaml\u0131 hata mesajlar\u0131 olu\u015fturman\u0131za ve bu hatalar\u0131 daha etkili bir \u015fekilde ele alman\u0131za olanak tan\u0131r. \u00d6zel hata t\u00fcrleri genellikle Bir web servisinden veri \u00e7ekme senaryosu \u00fczerinden \u00f6zel hata t\u00fcr\u00fc olu\u015fturmay\u0131 inceleyelim:<\/p>\n <\/code><\/p>\n Yukar\u0131daki kodda, Bu yakla\u015f\u0131m, kodunuzun daha temiz ve y\u00f6netilebilir olmas\u0131na olanak tan\u0131r. Hata t\u00fcrleriniz ne kadar spesifik olursa, onlar\u0131 yakalad\u0131\u011f\u0131n\u0131zda uygulaman\u0131z o kadar bilin\u00e7li kararlar verebilir. \u00d6rne\u011fin, bir Rust'\u0131n hata i\u015fleme felsefesinin temelini <\/code><\/p>\n \u00dcretim ortam\u0131nda G\u00fcvenli alternatifler, Bir web API'si geli\u015ftirdi\u011fimizi ve bu API'nin farkl\u0131 kaynaklardan veri \u00e7ekti\u011fini, bu verileri i\u015fledi\u011fini ve bir veritaban\u0131na kaydetti\u011fini varsayal\u0131m. Bu senaryoda bir\u00e7ok hata durumuyla kar\u015f\u0131la\u015fabiliriz: a\u011f ba\u011flant\u0131 sorunlar\u0131, d\u0131\u015f API'nin yan\u0131t vermemesi, ge\u00e7ersiz veri format\u0131, veritaban\u0131 ba\u011flant\u0131s\u0131n\u0131n kesilmesi veya yetkisiz eri\u015fim denemeleri. Rust'\u0131n hata i\u015fleme mekanizmalar\u0131 sayesinde, bu karma\u015f\u0131k senaryoyu bile sa\u011flam bir \u015fekilde y\u00f6netebiliriz.<\/p>\n \u00d6ncelikle, uygulaman\u0131n t\u00fcm katmanlar\u0131ndan gelebilecek hatalar\u0131 kapsayan merkezi bir \u00f6zel hata t\u00fcr\u00fc ( <\/code><\/p>\n Bu vaka analizinde, Modern web uygulamalar\u0131 genellikle mobil cihazlar taraf\u0131ndan da eri\u015filir. Bu nedenle, hata raporlama ve kullan\u0131c\u0131 aray\u00fcz\u00fc geri bildirimleri gibi konular\u0131n mobil uyumlulu\u011fu da g\u00f6z \u00f6n\u00fcnde bulundurulmal\u0131d\u0131r. Rust'\u0131n hata i\u015fleme mant\u0131\u011f\u0131, arka u\u00e7 sistemlerin sa\u011flaml\u0131\u011f\u0131n\u0131 art\u0131r\u0131rken, kullan\u0131c\u0131 aray\u00fcz\u00fc taraf\u0131nda (\u00f6rne\u011fin React Native, Flutter veya web tabanl\u0131 uygulamalar) hata mesajlar\u0131n\u0131n nas\u0131l g\u00f6sterilece\u011fi ayr\u0131 bir katman olarak ele al\u0131n\u0131r. Taray\u0131c\u0131da hata mesajlar\u0131n\u0131 g\u00f6stermek i\u00e7in basit bir CSS medya sorgusu \u00f6rne\u011fi:<\/p>\n <\/code><\/p>\n Bu CSS \u00f6rne\u011fi, hata mesajlar\u0131n\u0131n ve kod bloklar\u0131n\u0131n mobil cihazlarda daha okunakl\u0131 olmas\u0131n\u0131 sa\u011flamak i\u00e7in yaz\u0131 tipi boyutunu ve dolguyu ayarlar. Rust'\u0131n sa\u011flam hata y\u00f6netimi sayesinde, backend'de olu\u015fan hatalar\u0131n g\u00fcvenilir bir \u015fekilde yakalan\u0131p raporlanmas\u0131, bu hata mesajlar\u0131n\u0131n frontend'e iletilmesi ve kullan\u0131c\u0131lara anlaml\u0131 bir \u015fekilde sunulmas\u0131 i\u00e7in g\u00fc\u00e7l\u00fc bir temel sa\u011flar.<\/p>\n Rust'\u0131n temel hata i\u015fleme mekanizmalar\u0131 olduk\u00e7a g\u00fc\u00e7l\u00fc olsa da, daha b\u00fcy\u00fck ve karma\u015f\u0131k uygulamalarda hata y\u00f6netimini daha da kolayla\u015ft\u0131rmak i\u00e7in ileri d\u00fczey teknikler ve \u00fc\u00e7\u00fcnc\u00fc taraf k\u00fct\u00fcphaneler mevcuttur. Bu teknikler, \u00f6zellikle hata raporlama, hata ba\u011flam\u0131 ekleme ve farkl\u0131 mod\u00fcllerden gelen hata t\u00fcrlerini birle\u015ftirme gibi konularda geli\u015ftiricilere b\u00fcy\u00fck kolayl\u0131klar sa\u011flar.<\/p>\n En pop\u00fcler \u00fc\u00e7\u00fcnc\u00fc taraf hata k\u00fct\u00fcphanelerinden ikisi <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte, Asenkron Rust'ta hata i\u015fleme, temel olarak senkron Rust ile ayn\u0131d\u0131r, ancak Rust'\u0131n hata i\u015fleme felsefesi, geleneksel programlama dillerinin kar\u015f\u0131la\u015ft\u0131\u011f\u0131 bir\u00e7ok soruna k\u00f6kten \u00e7\u00f6z\u00fcm sunar. Makalemiz boyunca, Rust'\u0131n temel hata i\u015fleme mekanizmalar\u0131n\u0131, Rust ile geli\u015ftirme yapmak, ba\u015flang\u0131\u00e7ta biraz daha fazla disiplin gerektirse de, bunun kar\u015f\u0131l\u0131\u011f\u0131nda elde edece\u011finiz dayan\u0131kl\u0131l\u0131k, g\u00fcvenlik ve performans, uzun vadede \u00e7ok de\u011ferli bir yat\u0131r\u0131md\u0131r. Rust, yaz\u0131l\u0131m sistemlerini yaln\u0131zca \u00e7al\u0131\u015fan de\u011fil, ayn\u0131 zamanda g\u00fcvenilir ve s\u00fcrd\u00fcr\u00fclebilir k\u0131lan bir yakla\u015f\u0131m sunar. Dolay\u0131s\u0131yla, gelece\u011fin g\u00fcvenilir yaz\u0131l\u0131mlar\u0131n\u0131 in\u015fa etmek isteyen her geli\u015ftiricinin Rust'\u0131n hata i\u015fleme modelini benimsemesi, kilit bir ad\u0131md\u0131r.<\/p>\n Rust, \"null\" referanslar ve istisnalar (exceptions) yerine Hay\u0131r, Uygulaman\u0131z\u0131n karma\u015f\u0131k hata senaryolar\u0131n\u0131 daha spesifik ve anlaml\u0131 bir \u015fekilde ele almak istedi\u011finizde \u00f6zel hata t\u00fcrleri olu\u015fturmak gereklidir. Bu, hata mesajlar\u0131n\u0131n daha a\u00e7\u0131klay\u0131c\u0131 olmas\u0131n\u0131 sa\u011flar, hata kurtarma stratejilerini \u00f6zelle\u015ftirmenize olanak tan\u0131r ve farkl\u0131 mod\u00fcllerden gelen \u00e7e\u015fitli hata t\u00fcrlerini tek bir tutarl\u0131 yap\u0131 alt\u0131nda birle\u015ftirmenize yard\u0131mc\u0131 olur.<\/p>\n<\/li>\n Rust'\u0131n hata i\u015fleme mekanizmalar\u0131 genellikle performansa herhangi bir olumsuz etki yaratmaz. OptionResultOptionSome(T)<\/code>, de\u011ferin mevcut oldu\u011funu ve i\u00e7erdi\u011fini belirtirken, None<\/code> ise de\u011ferin olmad\u0131\u011f\u0131n\u0131 g\u00f6sterir. Bu, di\u011fer dillerdeki null veya nil de\u011ferlerine kar\u015f\u0131l\u0131k gelir, ancak \u00f6nemli bir farkla: Rust derleyicisi, bir Option<\/code> de\u011feri \u00fczerinde i\u015flem yapmadan \u00f6nce Some<\/code> veya None<\/code> durumunu kontrol etmenizi zorlar. Bu zorunluluk, kodunuzun bir None<\/code> durumuyla kar\u015f\u0131la\u015fmas\u0131n\u0131 ve bu durumu uygun \u015fekilde ele almas\u0131n\u0131 garantiler, b\u00f6ylece beklenmedik null referans \u00e7\u00f6kmelerini ortadan kald\u0131r\u0131r.<\/p>\nResultOk(T)<\/code>, i\u015flemin ba\u015far\u0131l\u0131 oldu\u011funu ve sonucu i\u00e7erdi\u011fini belirtirken, Err(E)<\/code> ise i\u015flemin ba\u015far\u0131s\u0131z oldu\u011funu ve hata bilgisini i\u00e7erdi\u011fini g\u00f6sterir. Bu, istisnalara g\u00fc\u00e7l\u00fc bir alternatiftir. Bir fonksiyon Result<\/code> d\u00f6nd\u00fcrd\u00fc\u011f\u00fcnde, \u00e7a\u011fr\u0131 yapan kod, hem ba\u015far\u0131 (Ok<\/code>) hem de ba\u015far\u0131s\u0131zl\u0131k (Err<\/code>) durumunu a\u00e7\u0131k\u00e7a ele almak zorundad\u0131r. Bu durum, hatay\u0131 “unutma” ihtimalini ortadan kald\u0131r\u0131r ve yaz\u0131l\u0131m\u0131n\u0131z\u0131n her olas\u0131 senaryoya kar\u015f\u0131 sa\u011flam olmas\u0131n\u0131 sa\u011flar. Rust, bu t\u00fcrleri kullanarak, hata i\u015fleme sorumlulu\u011funu geli\u015ftiricinin \u00fczerine y\u00fckler ancak bunu derleyici yard\u0131m\u0131yla kolayla\u015ft\u0131r\u0131r.<\/p>\npanic!<\/code> makrosu da bulunur. Ancak panic!<\/code>, genellikle programlama hatalar\u0131n\u0131 veya uygulaman\u0131n devam edemeyece\u011fi kurtar\u0131lamaz durumlar\u0131 i\u015faret etmek i\u00e7in kullan\u0131l\u0131r. Geli\u015ftirici hatalar\u0131 (\u00f6rne\u011fin, bir diziye ge\u00e7ersiz indeksle eri\u015fim) veya sistem kaynaklar\u0131n\u0131n t\u00fckenmesi gibi durumlar panic!<\/code> ile ele al\u0131nabilir. Fakat Rust’\u0131n felsefesi, kurtar\u0131labilir hatalar i\u00e7in Result<\/code> kullanmay\u0131 te\u015fvik ederken, panic!<\/code>‘i yaln\u0131zca son \u00e7are olarak saklamakt\u0131r. Bu dengeli yakla\u015f\u0131m, Rust’\u0131n hata i\u015fleme mekanizmalar\u0131n\u0131 hem g\u00fc\u00e7l\u00fc hem de esnek k\u0131lar, b\u00f6ylece g\u00fcvenilir yaz\u0131l\u0131m sistemleri in\u015fa etmek i\u00e7in sa\u011flam bir temel sunar.<\/p>\nResult<\/code> ve Option<\/code> ile G\u00fcvenilir Kod Nas\u0131l Yaz\u0131l\u0131r? (Uygulamal\u0131 K\u0131lavuz)<\/h2>\nResult<\/code> ve Option<\/code> t\u00fcrleriyle hata y\u00f6netimi, tipik bir “kontrol listesi” mant\u0131\u011f\u0131yla \u00e7al\u0131\u015f\u0131r. Derleyici, bu t\u00fcrleri d\u00f6nd\u00fcren bir fonksiyonun sonucunu i\u015flerken, olas\u0131 t\u00fcm senaryolar\u0131 ele ald\u0131\u011f\u0131n\u0131zdan emin olman\u0131z\u0131 ister. Bu, kodunuzun her zaman beklenen veya beklemeyen durumlara haz\u0131rl\u0131kl\u0131 olmas\u0131n\u0131 sa\u011flar. Bu t\u00fcrleri kullanman\u0131n en yayg\u0131n ve g\u00fc\u00e7l\u00fc yolu, match<\/code> ifadeleridir.<\/p>\nOption<\/code> \u00f6rne\u011fine bakal\u0131m:<\/p>\n\nfn bir_sayi_dondur(var_mi: bool) -> Optionbir_sayi_dondur<\/code> fonksiyonu bir Optionmain<\/code> fonksiyonunda, match<\/code> ifadesiyle hem Some<\/code> hem de None<\/code> durumunu ele al\u0131yoruz. E\u011fer bu durumlar\u0131 ele almazsak, Rust derleyicisi bize bir hata verecektir. Benzer \u015fekilde, Result<\/code> t\u00fcr\u00fc de benzer bir yap\u0131ya sahiptir ancak ek olarak bir hata bilgisi ta\u015f\u0131r:<\/p>\n\n#[derive(Debug)]\nenum BenimHatacim {\n DosyaBulunamadi,\n YetkiYetersiz,\n BilinmeyenHata,\n}\n\nfn bir_dosyayi_oku(dosya_adi: &str) -> Resultbir_dosyayi_oku<\/code> fonksiyonu, olas\u0131 hata durumlar\u0131n\u0131 temsil eden \u00f6zel bir BenimHatacim<\/code> enum'u ile bir Resultmatch<\/code> veya if let<\/code> gibi ifadelerle, ba\u015far\u0131l\u0131 (Ok<\/code>) ve hatal\u0131 (Err<\/code>) senaryolar\u0131 ayr\u0131 ayr\u0131 ele alabiliyoruz. \u00d6zellikle if let<\/code> yap\u0131s\u0131, sadece belirli bir durumu (\u00f6rne\u011fin sadece hatay\u0131) ele almak istedi\u011finizde kodunuzu daha k\u0131sa ve okunakl\u0131 hale getirir.<\/p>\n?<\/code> operat\u00f6r\u00fcd\u00fcr. Bu operat\u00f6r, bir Result<\/code> veya Option<\/code> de\u011ferini otomatik olarak a\u00e7ar ve e\u011fer de\u011fer Err<\/code> veya None<\/code> ise, mevcut fonksiyondan bu hatay\u0131 veya yoklu\u011fu hemen d\u00f6nd\u00fcr\u00fcr. Bu, hata yay\u0131l\u0131m\u0131n\u0131 (error propagation) son derece kolayla\u015ft\u0131r\u0131r ve i\u00e7 i\u00e7e ge\u00e7mi\u015f match<\/code> ifadelerinin \u00f6n\u00fcne ge\u00e7er:<\/p>\n\nfn zincirleme_islem() -> Result?<\/code> operat\u00f6r\u00fc, Rust'ta karma\u015f\u0131k hata i\u015fleme mant\u0131\u011f\u0131n\u0131 basitle\u015ftiren g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. Bu operat\u00f6r sayesinde, bir hata zincirinin herhangi bir a\u015famas\u0131nda olu\u015fabilecek bir problem, \u00e7a\u011fr\u0131 y\u0131\u011f\u0131n\u0131nda yukar\u0131 do\u011fru otomatik olarak yay\u0131l\u0131r ve en uygun yerde ele al\u0131nmas\u0131n\u0131 sa\u011flar. Bu sayede, kodun okunabilirli\u011fi artar ve geli\u015ftiriciler sadece ba\u015far\u0131l\u0131 ak\u0131\u015fa odaklan\u0131rken, hata durumlar\u0131n\u0131n derleyici taraf\u0131ndan kontrol edildi\u011finden emin olabilirler.<\/p>\n\u00d6zel Hata T\u00fcrleri Olu\u015fturma ve Y\u00f6netme: Uygulaman\u0131za \u00d6zg\u00fc \u00c7\u00f6z\u00fcmler<\/h3>\n
enum<\/code> yap\u0131s\u0131 kullan\u0131larak tan\u0131mlan\u0131r ve std::error::Error<\/code> trait'ini uygular.<\/p>\nstd::error::Error<\/code> trait'i, Rust'taki hata t\u00fcrleri i\u00e7in temel bir aray\u00fcz sa\u011flar. Bu trait'i uygulayan bir t\u00fcr, di\u011fer hata t\u00fcrleriyle birlikte kullan\u0131labilir ve hata yay\u0131l\u0131m\u0131 gibi mekanizmalarda sorunsuz bir \u015fekilde entegre olabilir. Ayr\u0131ca, hata mesajlar\u0131n\u0131n okunabilirli\u011fini art\u0131rmak i\u00e7in std::fmt::Display<\/code> ve hata ay\u0131klama i\u00e7in std::fmt::Debug<\/code> trait'lerinin de uygulanmas\u0131 yayg\u0131n bir pratiktir.<\/p>\n\nuse std::fmt;\nuse std::error::Error;\n\n#[derive(Debug)]\nenum WebHata {\n BaglantiHatasi(String),\n VeriFormatHatasi(String),\n SunucuHatasi(u16, String), \/\/ HTTP durum kodu ve mesaj\n YetkisizErisim,\n Bilinmeyen,\n}\n\nimpl fmt::Display for WebHata {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n match self {\n WebHata::BaglantiHatasi(msg) => write!(f, \"Ba\u011flant\u0131 kurulamad\u0131: {}\", msg),\n WebHata::VeriFormatHatasi(msg) => write!(f, \"Gelen veri format\u0131 hatal\u0131: {}\", msg),\n WebHata::SunucuHatasi(kod, msg) => write!(f, \"Sunucu hatas\u0131 ({}): {}\", kod, msg),\n WebHata::YetkisizErisim => write!(f, \"Yetkisiz eri\u015fim denemesi.\"),\n WebHata::Bilinmeyen => write!(f, \"Bilinmeyen bir hata olu\u015ftu.\"),\n }\n }\n}\n\nimpl Error for WebHata {\n fn source(&self) -> Option<&(dyn Error + 'static)> {\n \/\/ Bu metod, hatan\u0131n temel nedenini (source) belirtmek i\u00e7in kullan\u0131l\u0131r.\n \/\/ \u00d6rne\u011fin, BaglantiHatasi bir alt seviye a\u011f hatas\u0131ndan kaynaklanabilir.\n \/\/ Basitlik ad\u0131na burada None d\u00f6nd\u00fcr\u00fcyoruz.\n None\n }\n}\n\nfn veri_cek(url: &str) -> ResultWebHata<\/code> ad\u0131nda \u00f6zel bir enum tan\u0131mlad\u0131k. Bu enum, web istekleri s\u0131ras\u0131nda kar\u015f\u0131la\u015f\u0131labilecek farkl\u0131 hata t\u00fcrlerini (ba\u011flant\u0131 hatas\u0131, veri format\u0131 hatas\u0131, sunucu hatas\u0131 vb.) temsil ediyor. Display<\/code> ve Error<\/code> trait'lerini uygulamak, hata t\u00fcr\u00fcm\u00fcz\u00fcn kullan\u0131c\u0131 dostu bir \u015fekilde formatlanmas\u0131n\u0131 ve di\u011fer hata mekanizmalar\u0131yla uyumlu olmas\u0131n\u0131 sa\u011flar. \u00d6zellikle fmt::Display<\/code> uygulamas\u0131nda, her hata varyant\u0131 i\u00e7in a\u00e7\u0131klay\u0131c\u0131 bir mesaj olu\u015fturuyoruz.<\/p>\nYetkisizErisim<\/code> hatas\u0131nda kullan\u0131c\u0131y\u0131 oturum a\u00e7ma sayfas\u0131na y\u00f6nlendirebilirken, bir BaglantiHatasi<\/code> durumunda tekrar deneme mekanizmas\u0131 devreye sokabilirsiniz. Ayr\u0131ca, From<\/code> trait'ini kullanarak farkl\u0131 hata t\u00fcrlerini kendi \u00f6zel hata enum'unuza d\u00f6n\u00fc\u015ft\u00fcrebilirsiniz. Bu, \u00f6zellikle farkl\u0131 k\u00fct\u00fcphanelerden gelen \u00e7e\u015fitli hata t\u00fcrlerini tek bir uygulamaya \u00f6zg\u00fc hata t\u00fcr\u00fc alt\u0131nda toplamak istedi\u011finizde \u00e7ok kullan\u0131\u015fl\u0131d\u0131r, b\u00f6ylece hata y\u00f6netimi daha merkezi ve tutarl\u0131 hale gelir.<\/p>\npanic!<\/code> Kullan\u0131m Senaryolar\u0131 ve G\u00fcvenli Alternatifler Nelerdir?<\/h3>\nResult<\/code> ve Option<\/code> t\u00fcrleri olu\u015ftururken, dil ayn\u0131 zamanda kurtar\u0131lamaz durumlar i\u00e7in panic!<\/code> makrosunu da bar\u0131nd\u0131r\u0131r. Ancak panic!<\/code>, genellikle program\u0131n mant\u0131ksal olarak tutars\u0131z bir duruma girdi\u011fi veya geli\u015ftirici hatas\u0131 nedeniyle devam edemeyece\u011fi zamanlar i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu durumlar, genellikle uygulaman\u0131n \"normal\" ak\u0131\u015f\u0131n\u0131n bir par\u00e7as\u0131 olmayan ve mant\u0131ksal olarak ele al\u0131namayacak kadar ciddi olan sorunlard\u0131r.<\/p>\npanic!<\/code> ne zaman kullan\u0131lmal\u0131d\u0131r? \u0130\u015fte baz\u0131 uygun senaryolar:<\/p>\n\n
match<\/code> ifadelerinde varsay\u0131lan bir kolun tetiklenmesi), panic!<\/code> kullanmak mant\u0131kl\u0131d\u0131r. Bu, kodunuzdaki bir hatay\u0131 hemen tespit etmenize yard\u0131mc\u0131 olur.<\/li>\npanic!<\/code> kullanarak hen\u00fcz ele al\u0131nmayan durumlar\u0131 i\u015faretleyebilirsiniz. Ancak bu, \u00fcretim koduna ge\u00e7meden \u00f6nce kesinlikle Result<\/code> veya Option<\/code> ile de\u011fi\u015ftirilmelidir.<\/li>\n<\/ul>\npanic!<\/code>'in yan\u0131 s\u0131ra, Rust standart k\u00fct\u00fcphanesinde unwrap()<\/code>, expect()<\/code> ve unreachable!()<\/code> gibi panic!<\/code> tabanl\u0131 yard\u0131mc\u0131 fonksiyonlar da bulunur:<\/p>\n\n
unwrap()<\/code>: Bir Option<\/code> veya Result<\/code> de\u011ferini a\u00e7ar. E\u011fer Option<\/code> de\u011feri None<\/code> ise veya Result<\/code> de\u011feri Err<\/code> ise, panic!<\/code> tetikler.<\/li>\nexpect(\"mesaj\")<\/code>: unwrap()<\/code> ile ayn\u0131 \u015fekilde \u00e7al\u0131\u015f\u0131r ancak panic!<\/code> tetiklendi\u011finde \u00f6zel bir mesajla birlikte hata \u00e7\u0131kt\u0131s\u0131 verir. Bu, hata ay\u0131klama s\u0131ras\u0131nda daha bilgilendirici olmas\u0131n\u0131 sa\u011flar.<\/li>\nunreachable!()<\/code>: Kodun asla ula\u015fmamas\u0131 gereken bir noktaya ula\u015f\u0131ld\u0131\u011f\u0131nda panic!<\/code> tetikler. Derleyicinin belirli durumlar\u0131n asla olu\u015fmayaca\u011f\u0131n\u0131 anlamas\u0131na yard\u0131mc\u0131 olabilir.<\/li>\n<\/ul>\n\nfn bir_guvenli_islem(sayi: i32) -> Optionpanic!<\/code> kullanmak genellikle istenmeyen bir durumdur. Bir panic!<\/code>, Rust program\u0131n\u0131n varsay\u0131lan olarak mevcut i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131 (thread) sonland\u0131rmas\u0131na neden olur. E\u011fer bu ana i\u015f par\u00e7ac\u0131\u011f\u0131 ise, t\u00fcm uygulama \u00e7\u00f6ker. Bu nedenle, kullan\u0131c\u0131ya g\u00f6sterilen veya uzun s\u00fcreli \u00e7al\u0131\u015fan sunucu uygulamalar\u0131nda panic!<\/code>'i yaln\u0131zca ger\u00e7ekten kurtar\u0131lamaz durumlar i\u00e7in saklamak \u00f6nemlidir. \u00c7o\u011fu kurtar\u0131labilir hata durumu i\u00e7in Result<\/code> kullanmak, uygulaman\u0131z\u0131n daha dayan\u0131kl\u0131 ve \u00f6ng\u00f6r\u00fclebilir olmas\u0131n\u0131 sa\u011flayacakt\u0131r.<\/p>\npanic!<\/code> yerine, \u00f6zellikle k\u00fct\u00fcphanelerinizde, Result<\/code> d\u00f6nd\u00fcrmeyi tercih edin. \u00c7a\u011fr\u0131 yapan kod, hatay\u0131 nas\u0131l ele alaca\u011f\u0131na kendisi karar verebilir. E\u011fer bir fonksiyonda panic!<\/code> ka\u00e7\u0131n\u0131lmazsa, bunu d\u00f6k\u00fcmantasyonunuzda a\u00e7\u0131k\u00e7a belirtin.\n <\/div>\nunwrap()<\/code> ve expect()<\/code> gibi metotlardan ka\u00e7\u0131narak her zaman match<\/code>, if let<\/code>, ?<\/code> operat\u00f6r\u00fc veya map_or_else()<\/code> gibi Option<\/code> ve Result<\/code> metodlar\u0131n\u0131 kullanmay\u0131 i\u00e7erir. Bu sayede, uygulaman\u0131z\u0131n beklenmedik durumlarda bile kontroll\u00fc bir \u015fekilde davranmas\u0131n\u0131 sa\u011flars\u0131n\u0131z.<\/p>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131nda Hata \u0130\u015fleme Stratejileri: Bir Vaka Analizi<\/h2>\n
AppError<\/code>) tan\u0131mlamak iyi bir stratejidir. Bu enum<\/code>, farkl\u0131 alt sistemlerden gelen hata t\u00fcrlerini kendi varyantlar\u0131 alt\u0131nda toplayabilir ve std::error::Error<\/code> trait'ini uygulayarak geni\u015fletilebilir olmas\u0131n\u0131 sa\u011flar.<\/p>\n\nuse std::fmt;\nuse std::error::Error;\n\n\/\/ D\u0131\u015f k\u00fct\u00fcphane hatalar\u0131 i\u00e7in \u00f6rnek (varsay\u0131msal)\n#[derive(Debug)]\nstruct ExternalApiError {\n status_code: u16,\n message: String,\n}\nimpl fmt::Display for ExternalApiError { \/* ... *\/ }\nimpl Error for ExternalApiError { \/* ... *\/ }\n\n\/\/ Uygulamam\u0131z\u0131n ana hata t\u00fcr\u00fc\n#[derive(Debug)]\nenum AppError {\n Network(String),\n Database(String),\n Validation(String),\n Api(ExternalApiError),\n Internal(String),\n}\n\nimpl fmt::Display for AppError {\n fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n match self {\n AppError::Network(msg) => write!(f, \"A\u011f hatas\u0131: {}\", msg),\n AppError::Database(msg) => write!(f, \"Veritaban\u0131 hatas\u0131: {}\", msg),\n AppError::Validation(msg) => write!(f, \"Veri do\u011frulama hatas\u0131: {}\", msg),\n AppError::Api(e) => write!(f, \"D\u0131\u015f API hatas\u0131: {}\", e),\n AppError::Internal(msg) => write!(f, \"Dahili hata: {}\", msg),\n }\n }\n}\n\nimpl Error for AppError {\n fn source(&self) -> Option<&(dyn Error + 'static)> {\n match self {\n AppError::Api(e) => Some(e),\n _ => None,\n }\n }\n}\n\n\/\/ D\u0131\u015f hata t\u00fcrlerini AppError'a d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in From trait'i\nimpl FromFrom<\/code> trait'inin g\u00fcc\u00fcn\u00fc kullanarak ExternalApiError<\/code> gibi d\u0131\u015f hata t\u00fcrlerini otomatik olarak AppError<\/code>'a d\u00f6n\u00fc\u015ft\u00fcrebildi\u011fimizi g\u00f6r\u00fcyoruz. Bu sayede, hata yay\u0131l\u0131m\u0131 s\u0131ras\u0131nda farkl\u0131 katmanlardan gelen hatalar\u0131 tek bir \u00e7at\u0131 alt\u0131nda toplayabilir ve uygulama genelinde tutarl\u0131 bir hata y\u00f6netimi sa\u011flayabiliriz. ?<\/code> operat\u00f6r\u00fc, bu d\u00f6n\u00fc\u015f\u00fcmleri ve hata yay\u0131l\u0131m\u0131n\u0131 inan\u0131lmaz derecede kolayla\u015ft\u0131r\u0131r.<\/p>\n\n\/* Masa\u00fcst\u00fc g\u00f6r\u00fcn\u00fcm\u00fc *\/\n.error-message {\n font-size: 1.1em;\n padding: 15px;\n border: 1px solid #e0b4b4;\n background-color: #fdd;\n color: #a94442;\n margin-bottom: 15px;\n}\n\n\/* Mobil cihazlar i\u00e7in (768px geni\u015fli\u011fin alt\u0131) *\/\n@media screen and (max-width: 768px) {\n .error-message {\n font-size: 0.9em;\n padding: 10px;\n margin-bottom: 10px;\n \/* Mobil cihazlarda uzun hata mesajlar\u0131 i\u00e7in kayd\u0131rma \u00e7ubu\u011fu *\/\n overflow-x: auto;\n }\n .code-block {\n font-size: 0.8em;\n overflow-x: scroll;\n white-space: pre; \/* Kodu tek sat\u0131rda tut *\/\n word-break: normal;\n word-wrap: normal;\n }\n}\n<\/pre>\nRust ile Hata Y\u00f6netiminde \u0130leri D\u00fczey Teknikler ve En \u0130yi Uygulamalar<\/h3>\n
anyhow<\/code> ve thiserror<\/code>'d\u0131r:<\/p>\n\n
thiserror<\/code><\/strong>: \u00d6zellikle k\u00fct\u00fcphane geli\u015ftiricileri i\u00e7in tasarlanm\u0131\u015ft\u0131r. Kendi \u00f6zel hata enum<\/code>'lar\u0131n\u0131z\u0131 tan\u0131mlaman\u0131z\u0131 ve bu enum<\/code>'lara Display<\/code>, Error<\/code> ve From<\/code> trait'lerini otomatik olarak uygulaman\u0131z\u0131 sa\u011flar. Bu sayede, yukar\u0131da manuel olarak yapt\u0131\u011f\u0131m\u0131z uygulamalar\u0131 makro deste\u011fiyle \u00e7ok daha k\u0131sa ve az kodla ger\u00e7ekle\u015ftirebiliriz. Temiz ve yap\u0131land\u0131r\u0131lm\u0131\u015f hata t\u00fcrleri olu\u015fturmak i\u00e7in idealdir.<\/li>\nanyhow<\/code><\/strong>: Uygulama geli\u015ftiricileri i\u00e7in daha esnek ve kullan\u0131m\u0131 kolay bir hata sarmalama (error wrapping) k\u00fct\u00fcphanesidir. Farkl\u0131 t\u00fcrlerdeki hatalar\u0131 tek bir dinamik hata t\u00fcr\u00fc (anyhow::Error<\/code>) alt\u0131nda sarmalamak i\u00e7in idealdir. \u00d6zellikle main<\/code> fonksiyonlar\u0131nda veya ana uygulama mant\u0131\u011f\u0131nda hata yay\u0131l\u0131m\u0131n\u0131 basitle\u015ftirmek ve her hatay\u0131 detayl\u0131ca tan\u0131mlamak yerine h\u0131zl\u0131ca iletmek istedi\u011finizde \u00e7ok kullan\u0131\u015fl\u0131d\u0131r.<\/li>\n<\/ul>\n\n\/\/ Cargo.toml'a eklenmeli:\n\/\/ [dependencies]\n\/\/ thiserror = \"1.0\"\n\/\/ anyhow = \"1.0\"\n\nuse thiserror::Error;\nuse anyhow::Result;\n\n#[derive(Error, Debug)]\nenum MyServiceError {\n #[error(\"API hatas\u0131: {0}\")]\n ApiError(#[from] reqwest::Error), \/\/ reqwest hatas\u0131n\u0131 otomatik d\u00f6n\u00fc\u015ft\u00fcr\u00fcr\n #[error(\"Veritaban\u0131 hatas\u0131: {0}\")]\n DbError(#[from] sqlx::Error), \/\/ sqlx hatas\u0131n\u0131 otomatik d\u00f6n\u00fc\u015ft\u00fcr\u00fcr\n #[error(\"Ge\u00e7ersiz yap\u0131land\u0131rma: {0}\")]\n ConfigError(String),\n}\n\n\/\/ Bu fonksiyon MyServiceError d\u00f6nd\u00fcr\u00fcr\nfn get_config() -> std::result::Resultthiserror<\/code> ile nas\u0131l otomatik olarak hata t\u00fcrleri olu\u015fturuldu\u011funu ve #[from]<\/code> niteli\u011fi ile farkl\u0131 hata t\u00fcrlerinin nas\u0131l kolayca d\u00f6n\u00fc\u015ft\u00fcr\u00fcld\u00fc\u011f\u00fcn\u00fc g\u00f6rebiliriz. anyhow::Result<\/code> ise main<\/code> fonksiyonunun daha temiz olmas\u0131n\u0131 sa\u011flar, \u00e7\u00fcnk\u00fc herhangi bir Error<\/code> trait'ini uygulayan hata t\u00fcr\u00fcn\u00fc kabul edebilir. Bu, \u00f6zellikle hata t\u00fcr\u00fc hiyerar\u015fisi olu\u015fturmak istemedi\u011finiz veya h\u0131zl\u0131 prototipleme yapt\u0131\u011f\u0131n\u0131z durumlarda esneklik sunar.<\/p>\nanyhow::Error<\/code>'\u0131n .context(\"mesaj\")<\/code> metodu veya .wrap_err(\"mesaj\")<\/code> metodu ile hata ba\u011flam\u0131 eklemek, problemin nerede olu\u015ftu\u011funu anlaman\u0131z\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131r\u0131r.\n <\/div>\nasync\/await<\/code> bloklar\u0131 ve Future<\/code>'lar \u00fczerinde \u00e7al\u0131\u015f\u0131rken hata y\u00f6netimi de asenkron ba\u011flama ta\u015f\u0131n\u0131r. Result<\/code> t\u00fcrleri, asenkron fonksiyonlarda da yayg\u0131n olarak kullan\u0131l\u0131r ve ?<\/code> operat\u00f6r\u00fc yine hata yay\u0131l\u0131m\u0131 i\u00e7in en pratik y\u00f6ntemdir. Asenkron uygulamalarda, bir i\u015flemin ba\u015far\u0131s\u0131z olmas\u0131 durumunda di\u011fer asenkron g\u00f6revlerin nas\u0131l etkilenece\u011fini d\u00fc\u015f\u00fcnmek \u00f6nemlidir; bu, genellikle do\u011fru await<\/code> noktalar\u0131n\u0131 ve hata kurtarma stratejilerini uygulamay\u0131 gerektirir.<\/p>\nSonu\u00e7: Rust ile G\u00fcvenilir Yaz\u0131l\u0131mlara Giden Yol<\/h2>\n
Option<\/code> ve Result<\/code> t\u00fcrlerinin derleyici taraf\u0131ndan zorunlu k\u0131l\u0131nan kullan\u0131m\u0131, \"null\" referans hatalar\u0131n\u0131 ve g\u00f6zden ka\u00e7an istisnalar\u0131 ortadan kald\u0131rarak, yaz\u0131l\u0131m\u0131n\u0131z\u0131n \u00f6ng\u00f6r\u00fclebilirli\u011fini ve g\u00fcvenilirli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Bu yakla\u015f\u0131m, sadece sistem \u00e7\u00f6kmelerini engellemekle kalmaz, ayn\u0131 zamanda geli\u015ftiricilerin potansiyel hata durumlar\u0131n\u0131 daha en ba\u015f\u0131nda, yani derleme zaman\u0131nda ele almas\u0131n\u0131 sa\u011flar.<\/p>\nResult<\/code> ve Option<\/code> t\u00fcrlerinin nas\u0131l kullan\u0131ld\u0131\u011f\u0131n\u0131, ?<\/code> operat\u00f6r\u00fcn\u00fcn hata yay\u0131l\u0131m\u0131n\u0131 nas\u0131l basitle\u015ftirdi\u011fini ve \u00f6zel hata t\u00fcrlerinin nas\u0131l tan\u0131mlan\u0131p y\u00f6netilece\u011fini detayl\u0131 bir \u015fekilde inceledik. Ayr\u0131ca, panic!<\/code> makrosunun do\u011fru kullan\u0131m senaryolar\u0131na de\u011findik ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda hata y\u00f6netimi stratejilerini bir vaka analiziyle g\u00f6sterdik. Son olarak, anyhow<\/code> ve thiserror<\/code> gibi \u00fc\u00e7\u00fcnc\u00fc taraf k\u00fct\u00fcphanelerle ileri d\u00fczey hata y\u00f6netim tekniklerine g\u00f6z att\u0131k.<\/p>\nS\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n
OptionResultpanic!<\/code> kullanmak her zaman k\u00f6t\u00fc m\u00fcd\u00fcr?<\/strong><\/p>\npanic!<\/code> her zaman k\u00f6t\u00fc de\u011fildir, ancak kullan\u0131m amac\u0131 kritiktir. panic!<\/code>, genellikle programlama hatalar\u0131n\u0131 (\u00f6rne\u011fin, bir dizine ge\u00e7ersiz indeksle eri\u015fim) veya uygulaman\u0131n mant\u0131ksal olarak devam edemeyece\u011fi kurtar\u0131lamaz durumlar\u0131 i\u015faret etmek i\u00e7in kullan\u0131l\u0131r. Kurtar\u0131labilir hatalar i\u00e7in Result<\/code> kullanmak, panic!<\/code>'i ise son \u00e7are olarak saklamak en iyi uygulamad\u0131r.<\/p>\n<\/li>\n?<\/code> operat\u00f6r\u00fc neden bu kadar \u00f6nemlidir?<\/strong><\/p>\n?<\/code> operat\u00f6r\u00fc, Rust'ta hata yay\u0131l\u0131m\u0131n\u0131 (error propagation) b\u00fcy\u00fck \u00f6l\u00e7\u00fcde basitle\u015ftiren g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. Bir Result<\/code> veya Option<\/code> de\u011feri Err<\/code> veya None<\/code> ise, ?<\/code> operat\u00f6r\u00fc bu hatay\u0131 veya yoklu\u011fu hemen mevcut fonksiyondan d\u00f6nd\u00fcr\u00fcr. Bu, i\u00e7 i\u00e7e ge\u00e7mi\u015f match<\/code> ifadelerinden ka\u00e7\u0131narak kodun daha temiz, k\u0131sa ve okunabilir olmas\u0131n\u0131 sa\u011flar.<\/p>\n<\/li>\nOption<\/code> ve Result<\/code> enum'lar\u0131, s\u0131f\u0131r maliyetli soyutlamalar (zero-cost abstractions) olup, derleyici taraf\u0131ndan etkili bir \u015fekilde optimize edilir. \u0130stisnalar gibi \u00e7al\u0131\u015fma zaman\u0131nda ek y\u00fck getiren mekanizmalar\u0131n aksine, Rust'\u0131n yakla\u015f\u0131m\u0131 derleme zaman\u0131nda kontrol sa\u011flar ve \u00e7al\u0131\u015fma zaman\u0131nda ek bir maliyet getirmez.