Exception Sınıfından Korkmayın

throw new XYZException yazmaktan korkmayın.

You can access the English version via this link.

Photo by Nong Vang on Unsplash

Bu yazıda exception oluşturmaktan ve avantajlarından bahsedeceğiz. Ayrıca bir metot içerisinde exception oluşturma ile işlem sonucu döndürme arasındaki yaklaşım farklarından da bahsedeceğiz.

Exception Oluşturma Senaryoları

Split adında bir metot yazdığımızı düşünelim. Bu metoda ödenecek toplam tutarı ve ödeme işlemine katılacak kişilerin listesini parametre olarak gönderdiğimizi varsayalım. Metodumuzun sonuç olarak da bir kişinin ödemesi gereken tutarı döndüğünü hayal edelim. Ödeme işlemine katılacak kimse olmazsa C# dilinde yürütülen bölme işlemi DivideByZeroException tipinden bir exception oluşturmaktadır. Bu durumda exception tipini değiştirerek hem kendi açıklamamızı yazabilir hem de duruma daha uygun bir hata tipini seçebiliriz. Örnek senaryomuzda hatanın sebebi sayının sıfıra bölünememesi olsa da durumu metota verilen parametrenin geçerli yapıda olmadığı yönünde bir exception tipi ile daha iyi temsil edebiliriz.

Bir masa üstü programı olarak hesap makinası yazdığımızı düşünelim. Toplama işlemi butonuna basıldığı zaman TextBox içerisinde yer alan değerleri toplayarak sonuç döndüğümüzü varsayalım. Aldığımız değerlerin sayı olmaması halinde işleme devam edebilme olanağımız yoktur. İşleme devam edemeyeceğimiz bu gibi durumlarda exception oluşturup süreci sonlandırabiliriz.

Bazı durumlardaysa aldığımız parametre uygun format ve değer aralığında olsa dahi işlemi yürütemeyebiliriz. Bu gibi istisnai durumlar da bizim exception oluşturduğumuz senaryolardan biri olacaktır.

Elinizde şehirlerin yer aldığı bir kaynak olduğunu düşünelim. Kullanıcı bir Id değeri veriyor ve bu şehrin bilgisini almak istiyor. Normal bir durumda beklenti bu değere ait bilginin kaynakta bulunmasıdır. İstisnai durumlarda ise veri kaynağına baktığımız zaman talep edilen Id değerine sahip bir kayıt bulamayabiliriz. Bu durumda da var olan exception yapılarını kullanabileceğimiz gibi kendi tanımlayacağımız exception tiplerini kullanarak da süreci sonlandırabiliriz.

Exception Oluşturmak veya Operasyon Sonucu Dönmek

Exception oluşturmak veya hata kodu içeren işlem sonuçları dönmek birbiri yerine kullanabileceğimiz iki senaryodur. Bu iki senaryonun da bazı dezavantajları vardır. Yazının bu kısmında bu dezavantajlara değineceğiz.

Not: Bu kısımda yer alan örnek kod parçalarına GitHub linki üzerinden erişebilirsiniz.

1 — Kod uzunluğu

Aşağıda ilk kod parçasında Id değerine bağlı şehir bulunamadığı zaman veya şehir ismi ile ilgili hava sıcaklığı değerine ulaşılamadığı zaman hata fırlatan Repository ve Proxy sınıfları tasarladığımız durumu görmekteyiz. Bu durumda hataların GlobalExceptionHandler tarafından yakalanıp uygun hata kodlarının kullanıcıya dönüldüğünü düşünelim. Servis katmanının çok yalın ve okuması çok kolay olduğunu görebilmekteyiz.

Buna karşılık exception yönetimi yapmadığımız, OperationResult tipinden dönüş yaptığımız durumda aynı işlevi yerine getiren kod bloğu aşağıda yer almaktadır. Repository ve Proxy sınıflarına yapılan çağrılar sonucu gelen cevabın istediğimiz sonucu içerip içermediğine dair kontroller kodun uzamasına sebep olduğu gibi okunaklılığı da önemli ölçüde azaltmaktadır.

2 — Cevap kontrolünün atlanması

Yukarıdaki örnekte Repository veya Proxy sınıfından bir metot çağrısı yaptıktan sonra dönüş değerinin her defasında kontrol edilmesinin gerekli olduğunu gördük. Bu kontrolün atlandığı durumda yani OperationResult işleminin başarılı olarak bittiğini kontrol etmeden Result değeri kullanılmaya çalışıldığı durumlarda NullReferenceException oluşacaktır. Bu da uygulamamızda istemeyeceğimiz bir durumdur.

1 — Performans Düşüşü

OperationResult oluşturduğumuz durumda cevabı başarısız veya başarılı olarak nitelendiriyoruz. Bu durumun yazılım açısından bir farkı yoktur. Bu sebeple performans farkı oluşmamaktadır. Exception oluşturmak ise maliyetli bir işlemdir. Bu sebeple başarısız olarak sonuçlanacak işlem yürüttüğümüz zaman kodun çalışma süresi uzamaktadır.

  • Var olan bir şehir ile işlem yatığımız zaman (CityId = 1) exception kullanan servis yapımız çok ufak bir farkla daha performanslı çalışmaktadır. Bunun sebebi daha az kontrol bloğu ile uğraşıyor olmasıdır.
  • Var olmayan bir şehir ile işlem yaptığımız zaman (CityId = 0) exception objesini oluşturmanın maliyeti sebebiyle işlemimizin sonuçlanması çok daha fazla zaman almaktadır.

Yazılım geliştirmenin temelinde yer alan konu burada da karşımıza çıkmaktadır. İki çözüm arasındaki artılar ve eksiler kıyaslanarak kendi durumumuza en uygun çözümü bulmamız gerekmektedir.

Exception oluşturulan durumların toplam işlem sayısına göre çok daha az sayıda olmasını beklediğim için performans konusundaki dezavantajı göz ardı etmekteyim. Kod okunabilirliğini arttırma ve beklenmedik hataların oluşma ihtimalini düşürmesi avantajını da göz önüne alınca daha sık kullandığım yöntem hata oluşturma yöntemi olmaktadır.

Umarım yararlı bir yazı olmuştur. Diğer yazılarıma göz atmak için bu linke tıklayabilirsiniz.

--

--

var software = ConvertFrom(caffeine)

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store