Birinci Şans..İkinci Şans..Nedir Bu Şanslar?!

   Visual Studio ile bir uygulamada hata ayıklarken çıktı (Output) penceresini takip ettiyseniz aşağıdakine benzer bir mesajla mutlaka karşılaşmışsınızdır;

A first chance exception of type ‘System.ArgumentException’ occurred in mscorlib.dll

Daha genel haliyle;

A first chance exception of type ‘[HATA]‘ occurred in [Assembly]

   Bu hata mesajını çıktı penceresinde pek çok kereler görülmesine karşın çoğunda da uygulamanızda bir hata oluşmayacaktır. Peki nedir bu ilk hata şansı? Neden bu hatalar her zaman uygulamamın durmasına neden olmuyor?

    Bu soruların yanıtı için öncelikle Windows’un Structured Exception Handling (SEH) sinyal mekanizması hakkında özet bir bilgi vermek faydalı olacaktır. Structured exception handling sinyal mekanizmasında, bir windows uygulamasında hata olması durumunda çalıştırılacak kodlar bir linked list içerisinde tutulmaktadır. SEH’te try/catch bloğu içerisine alınan her bir kod parçacığı için kodun çalıştığı thread bilgilerinin bulunduğu Thread Information Block (FS:[0]) içerisinde ilgili hata kaydının bulunduğu linked list’e hata oluşabilecek kodun ve hata durumunda çalıştırılacak kodun adreslerinin bulunduğu bir girdi eklenmektedir. Bu blok içerisinde yer alan her bir alt try/catch’te benzer şekilde linked list’e bir sonraki girdi olarak ekleme yapılmaktadır. try/catch içerisine alınan kodda hata olması durumunda bu linked list içerisinde bu kod bloğu için eklenmiş en son girdiye gidilerek çalıştırılması gereken kodun adresi bulunur ve işletilir. İşletilen bu kod, hatayı yakalayarak düzeltebilirse uygulamaya işleyişine devam edebileceğine dair EXCEPTION_CONTINUE_EXECUTION sinyalini gönderecek ve uygulama kaldığı yerden çalışmaya devam edecektir. Bazı durumlarda hata düzeltilemeyerek bir üst hata ayıklama bloğuna geçilmesi için EXCEPTION_CONTINUE_SEARCH yanıtı verilebilir. Bu durumda linked list içerisindeki bir önceki kayda gidilerek aynı işlem tekrarlanır. Bu süreç EXCEPTION_CONTINUE_EXECUTION yanıtı alınana ya da linked list’in en başına gelene kadar devam edecektir. Linked list’in en başına gelinmesi durumunda hata yakalanamamış olacağından uygulama hata yanıtı ile sonlanacaktır.

    SEH hakkındaki bu özet bilgi sonrasında, çalışan bir işleme bir debugger’ın dahil olması halinde Windows süreci biraz daha farklı işletecektir. Bu durumda Windows bu linked list’e ufak bir ekleme yaparak hata alındığında kullanıcının yazmış olduğu hata ayıklama kodlarının işletildiği yukarıdaki süreç öncesinde debugger’ın ilgili fonksiyonunun çalışmasını sağlayacak girdiyi ekleyecektir. Bunun anlamı hata durumunda tüm kullanıcı kodlarından önce hata bilgisi debugger’a gönderilerek nasıl hareket edileceğine dair bir yanıt beklenmesidir. Debugger aynı kullanıcı hata ayıklama kodları gibi hatayı düzelterek/hatayı yok sayarak işleyişe devam edilmesini talep edebileceği gibi herhangi bir müdahale yapmayarak kullanıcı kodlarının çalışmasını da sağlayabilir. İşte tüm kullanıcı hata ayıklama kodlarının çalışması öncesinde debugger’ın müdahalesine izin veren bu bildirim İlk Şans Hatası (First Chance Exception) olarak adlandırılmaktadır.

   Yukarıda da belirttiğim üzere hata yakalama sürecinde debugger herhangi bir düzeltme yapmaz/yapamaz ise kullanıcı kodlarının işletimine geçilecektir. Eğer hiç bir kullanıcı hata ayıklama kodu yoksa ya da mevcut kodların hiç birisi hatayı düzeltememesi nedeniyle listenin başına ulaşılırsa Windows müdahale etmesi amacıyla hatayı tekrar debugger’a iletecektir. Kullanıcı kodlarınca yakalanamayan hatalarda debugger’ın son kez müdahale edebilmesine olanak sağlayan bu ikinci bildirim de İkinci Şans Hatası (Second Chance Exception) olarak adlandırılmaktadır.

   İlk şans hatasını her zaman için kritik bir hata olarak yorumlamak yanlış olacaktır. Windows işletim sisteminde yazılımsal olduğu kadar donanımsam sıkıntılarda da hata bildirim mekanizmasının işlediğini düşünecek olursak, bazı iş mantıklarında ilk şans hatası uygulamanın iş mantığında bir dallanmaya neden olabilecek bir iş kuralı olabilir. Bunun en güzel örneği eski sistemlerde yer alan floppy disk sürücülerinin bir okuma denemesi yapmadan floppy diskin takılı olup olmadığının anlaşılmamasını gösterebiliriz. Bu senaryoda, sistem diski okumaya çalışacak ve ancak aldığı hata ile takılı bir floppy disk olmadığını öğrenebilecektir. Bu gibi bir hatanın debugger ile harici olarak işlenmesi iş mantığını bozabilecek durumlara da neden olacaktır. Bu sebepledir ki modern debugger’lar genellikle ilk şans hatasına müdahale etmeyerek sadece, yazımında başında belirttiğim Visual  Studio’nun çıktı penceresinde gördüğünüz gibi, loglama yapmayı tercih etmektedir. Kullanıcı kodlarının hatayı yakalayamaması neticesinden tetiklenen ikinci şans hatasında ise uygulamanın çalışmasını durduracak kritik hatalar olduklarından uygulamanın çalışması askıya alınarak debugger arayüzünden kullanıcının müdahale etmesi sağlanmaktadır.

   Bazı istisnai senaryolarda ise yukarıda bahsettiğimin aksine ilk şans hatasıyla ulaştığımız hata bilgisi bizi çözüme ulaştırabilir. Bazı uygulamalar hatayı yakalayarak ek işlemler yapabilmekte, ardından da yeni bir hata mesajı oluşturarak bunu gönderirler. Bu durumda hata bir üste iletilmeden yeniden bir ilk şans hatası bildirimi yapılacak, debugger bu bildirimi es geçtiğinde yeni hata üst bloklara taşınacak ve eğer hatayı yakalayan bir hata ayıklama kodu olmazsa ikinci şans hatası olarak yeniden debugger’a gelecektir. Bu noktada alınacak bilgi bizi gerçek hataya değil uygulamamız içerisinden bizm tetiklediğimiz hataya yönlendirecek ve zaman kaybedilmesine neden olabilecektir.

   Windows’un hata mekanizması ile ilgili ek bir bilgi; Windows XP ve üstü işletim sistemlerinden Structured Exception Handling (SEH) sinyal mekanizması yanında Vectored Exception Handling (VEH) sinyal mekanizması sunulmaktadır. Bu makalenin konusu olmaması nedeniyle detaylarına değinmemekle birlikte, VEH sinyal mekanizmasını kullanan uygulamaları dinleyen debugger’ların hata yakalama mantığında bir değişiklik olmadığını ve yukarıda sıraladığım birinci ve ikinci şans hataların bu işlemler için de geçerli olduğunu belirtmeliyim.

   Visual Studio varsayılan olarak birinci şans hatalar oluştuğunda sadece çıktı penceresine bir uyarı notu düşmekte, ikinci şans hatasından ise uygulamanın çalışmasını duraklatarak debug edilebilmesine izin vermektedir. Daha detaylı hata ayıklama oturumlarında birinci şans hatalarının fırlatıldığı sırada debug edilmesi gerekebilir ya da ikinci şans hatalarında uygulamanın duraklatılmaması önemli olabilir.

Visual Studio tarafından birinci ya da ikinci bildirimde hataların yakalanması ayarlanabilir

    Bu gibi durumlarda, Visual Studio debug menüsünde yer alan exceptions seçeneğine basıldığında açılan Exceptions diyalogunu kullanarak istediğiniz yapılandırmayı yapmanız mümkündür. Açılan bu pencere bizlere sistemde bulunan hata türlerini listeleyerek birinci ve ikinci şans hataların yakalanıp yakalanmayacağını ayarlamaya imkan vermekte. Yukarıdaki ekran görüntüsünde yer alan Thrown sütünu birincil şans hataları temsil ederken, User-unhandled sütünu ikinci şans hatalarını belirtmekte.

Fatih Boy

Ankara'da yaşayan Fatih, bir kamu kurumunda danışman olarak çalışmaktadır. ALM süreçleri, kurumsal veri yolu sistemleri, kurumsal altyapı ve yazılım geliştirme konularında destek vermektedir. Boş zamanlarında açık kaynak kodlu projeler geliştirmeyi ve bilgisini yazdığı makalelerle paylaşmayı seven Fatih, aynı zamanda Visual C# ve Visual Studio teknolojileri konusundan Microsoft tarafından altı yıl üst üste MVP (En Değerli Profesyonel) ödülüne layık görülmüştür. İş hayatı boyunca masaüstü uygulamaları, web teknolojileri, akıllı istemciler gibi konularda Asp.Net, Php, C#, Java programlama dilleri ve MySql, MsSql ve Oracle gibi veritabanı yönetim yazılımları ile çalışmıştır. İngilizce ve Türkçe olarak yayınlanan makalelerini gerek İngilizce bloğunda, gerekse de Türkçe bloğunda bulabileceğiniz gibi web sitesinden de açık kaynak kodlu geliştirdiği yazılımlarına ulaşabilirsiniz. vCard - Twitter - Facebook - Google+

4 yorum

  1. Eralp   •  

    Gerçekten faydali bir yazi.Eline sağlık Fatih.

  2. ferhatk   •  

    C# ta eskiden yapmış olduğum bir projeyi açarken;
    Could not resolve mscorlib for target framework ‘.NETFramework,Version=v4.0’. This can happen if the target framework is not installed or if the framework moniker is incorrectly formatted.
    hatası alıyorum. Mscorlib’le alakalı olduğu için buraya yazdım. Nasıl düzelteceğimi yazarsanız çok sevinirim. Şimdiden teşekkürler

    • Fatih Boy   •     Yazar

      Merhaba Ferhat, büyük ihtimalle hatayı aldığın bilgisayarda .net framework 4.0 kurulu değil. Kurduktan sonra yeniden denersen hata almayacaksın.

  3. ferhatk   •  

    Merhaba hocam. Vs studio 2012 kullanıyorum. 2012 yi kurarken otomatik .net framework 4.5 yüklüyor. Daha üst sürüm olduğu için işe yarayacağını ve sorunun .net fr 4.0 ile alakalı olmadığını düşündüm. Çünkü .net fr 4.5 i kaldırıp 4.0 yüklediğimde bu seferde vs 2012 çalışmadı hocam. Sorunu çözemedim daha. Bu arada ben Dpü bilgisayar müh. öğrencisiyim. Geçenlerde bölümde konferans vermiştiniz hocam 🙂

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir