Belki tahmin etmediğin bir hata çıkacak? Veya anlık, kullanıcı hareketine göre bir hata çıkacak?Bir geliştirici zaten hatanın nerede olduğu bilir. Bunu neden try-catch alıyor hala anlamadım. Donduran, kapatan kod satırı neyse onunla ilgilenmez mi zaten?
Bilemeyebilir, karmaşık programlarda hatanın nereden geleceğini tahmin edemezsin. Belki de 100.000 satırlık bir uygulama yazıyorsun, her program 20 satırlık hesap makinelerinden ibaret değil ki.Bir geliştirici zaten hatanın nerede olduğu bilir.
Mesela kullanıcıdan alınan input hatalı. Bunu tespit etmek için kullanılabilir. Örneğin;Bir geliştirici zaten hatanın nerede olduğu bilir. Bunu neden try-catch alıyor hala anlamadım. Donduran, kapatan kod satırı neyse onunla ilgilenmez mi zaten?
Tamam try-catch ile bu durumu ortadan kaldırılır ama onun yerine hata veren satırı gözden geçirip düzeltmek daha mantıklı olmaz mı?Çalışabilir. Syntax dışındaki diğerException
lar programı durdurmasın diye try-catch kullanırsın.
Ama try-catch'e hatalı olduğu bilinen kod satırı eklenmiyor mu?Bilemeyebilir, karmaşık programlarda hatanın nereden geleceğini tahmin edemezsin. Belki de 100.000 satırlık bir uygulama yazıyorsun, her program 20 satırlık hesap makinelerinden ibaret değil ki.
Zaten düzelteceksin, bu sadece programın yanıtsız kalmasını önlüyor. Try-catch ile yakaladığın hatayı kendi log tablona yazabilir veya mail atabilirsin. Böyle programındaki hataları takip edersin.Tamam try-catch ile bu durumu ortadan kaldırılır ama onun yerine hata veren satırı gözden geçirip düzeltmek daha mantıklı olmaz mı?
Hayır, try-catchi hata olacağını bildiğin yere koymazsın. Mümkünse tüm kodunu try-catch'e koyarsın ki hataları yakala ve ona göre yönet.Ama try-catch'e hatalı olduğu bilinen kod satırı eklenmiyor mu?
Bunun için hep switch case kullandım da. Try-catch'e gerek duymadım pek. Arayüzde değişebilir ama.Mesela kullanıcıdan alınan input hatalı. Bunu tespit etmek için kullanılabilir. Örneğin;
Bu nedenle kullanılabilir.
- Sayı değeri isteyen bir program olsun.
- Kullanıcı karakter içeren bir input girsin.
İşte gelebilecek hatalara göre koşul yazmaya defensive programming diyebilirsin.Bunun için hep switch case kullandım da. Try-catch'e gerek duymadım pek. Arayüzde değişebilir ama.
Şimdi Call-stack kavramını öğrenmeden önce bu hataları önceden bilmiyoruz galiba.Call-stack diye bir sey var. Once bunu ogrenmelisin. A B'yi cagirir, B C'yi cagirir vs.
Hata alindigi zaman bu hata stack uzerinde yukari dogru "firlatilir".
Sen Try blogu actigin zaman, ki bunu catch ile bitirmek zorunda degilsin, try-finally de kullanilabilir kimi dillerde; "Benden sonraki cagrilarda firlatilan hatalari bu blokta handle edebilirim" demis oluyorsun. Ne tarz hatalari handle edecegini de yazdiysan catch blogunda belirtirsin.
Futbolcularin hatalarini teknik direktor yakalar, teknik direktorun hatasini sportif direktor yakalar, sportif direktorun hatasini klup baskani yakalar. Boylelikle futbolcunun hatasinin klup baskanina kadar gitmesinin onune gecmis de olursun. Gereksiz mesgul etmezsin kimseyi
Kurguladigin hiyerarsiye gore hangi grubun hatasini hangi elemanin yakalayacagi programmerin kontrolunde.
OO disindaki paradigmalarda surec farkli isliyor. Try-catch yaklasimi her zaman dogru degil.
Karmaşık değil. Gayet basit.Arkadaşlar karmaşık bir şey.
try {
// dene...
}
catch {
// hata verirse bunları yap...
}
finally {
// işlemler bitince...
}
Bu sitenin çalışmasını sağlamak için gerekli çerezleri ve deneyiminizi iyileştirmek için isteğe bağlı çerezleri kullanıyoruz.