.Net Core Exception Handling Middlewares | Dependency Injection
Вставка
- Опубліковано 2 гру 2020
- Bu videomuzda daha önce anlamış olduğum Dependency Injection kavramını da kullanarak .Net Core üzerinde merkezi bir hata yakalama mekanizması gereçekleştirdik.
In this video, by using Dependency Injection, which I have mentioned in earlier videos, we build a centralized exception handling mechanism that allows you to catch all unhandled exceptions in your project.
#dotnetcore #exceptionhandling #middlewares
Kanala Abone Olmayı Unutmayın!
To Subscribe: bit.ly/3kvj2vw - Наука та технологія
Emeğinize sağlık.
Emeğine sağlık
Çok teşekkürler.
🚀🚀🚀🚀
Hocam exception gibi Ilogger'uda bu yöntemle kulanabiliriz değil mi?
try-catch ve exception konusunda mantık olarak eksiğim var. Anlayamadığım şey şu; örneğin validation yaptığımızı düşünelim, eğer herhangi bir sorun varsa geriye ErrorResult gibi bir sınıf ve içerisinde hataları dönebiliriz. Aynı şey iş kuralları veya diğer yapılar içinde geçerli. Neden exception fırlatıp daha sonra bunu yakalamaya çalışıyoruz? Try-catch maliyetli bir şey değil mi?
if gibi kontrol yapıları ile kontrol edilemeyen hataları yakalamak için try catch kullanılabilir bunu anlıyorum. Elimiz ile kontrol edip başarılı veya başarısız gibi durumları dönebileceğimiz yerlerde exception fırlatmanın mantığı nedir?
try-except yapıları en çok iç içe çağırılan fonksiyonlardaki aksiyonları algılamak ve buna göre aksiyon almak için kullanılıyor. Bir fonksiyon düşünün ve bunun içinde başka servislere giderek başka işlemler yapılıyor. Bu başka işlemler yapılan metodların hepsinin içine teker teker girip if yazmak lazım. Daha sonra bu if leri kendi ana metodumuzda da yazmak lazım ki içerideki metodlarda bir hata olup olmadığını anlayabilelim. Dolayısı ile hata olup olmadığını kontrol etmek istediğimiz her noktada işler uzamaya başlıyor. Ne kadar çok metod çağırıyorsak o kadar fazla if yazmış da oluyoruz aynı zamanda. Ama bunların hepsini, tek bir metod içinde try-catch içinde yazmak işimizi kolaylaştırıyor. Hem de metodların içinde bir hata olduğunda exception fırlatarak istediğimiz mesajı içine ekleyebiliyoruz. Diğer bir avantajı ise exception fırlattığımız kod satırından sonraki satırlar çalıştırılmıyor. Eğer exception fırlatmadan if ile kontrol etseydik tüm if lerimiz if-else bloğu şeklinde olurdu. Eğer hata yoksa şu kod satırlarını çalıştır, varsa şunları çalıştır gibi.
@@TechBuddyTR Evet böyle düşününce mantılı. Sizin videolarınız altında çok soru soruyorum kusura bakmayın ama sizi yakalamışken de sormak istiyorum :) Web API söz konusu olduğunda exception'ı yakalayıp geriye json formatında bir mesaj dönmek nispeten kolay gibi. Peki eğer MVC gibi web app olsaydı exceptionları nasıl ele alırdık? Sonuçta orada view var ve kullanıcıya bir şey gösterilmesi gerekiyor. Bu konuda da bilginizden faydalanmak isterim :)
@@aslanamca8225 Estağfurullah, istediğiniz gibi sorabilirsiniz sorularınızı pek tabi ki. MCV projelerinde eğer IoC kullanabiliyorsak belki exception için interrupter'lar yazabiliriz. Eğer kullanamıyorsak da controler içerisindeki metodlarda yazabiliriz try-catch bloklarımızı. View içerisinde oluşacak hataları da ikiye ayırmak lazım. Eğer view açılırken bir hata oluşuyorsa zaten controller da yakalayabiliriz bunu sorun olmaz ama sayfa açıldıktan sonra bir jquery veya js kullanırken bir hata alıyorsak orada da elle hata yakalamak gerekecek gibi duruyor
eğitim için teşekkürler. 8:25'te uygulamanın invoke metodu içerisinden devam edeceğini söyledik ama bu işlem nasıl gerçekleşiyor. invoke metodunu tetikleyen etmen nedir orada
Biz bu Middleware'ı .NET Core içerisine ekliyoruz. Dolayısı ile Invoke metodu da .NET sisteminin kendisi tarafından tetikleniyor.
@@TechBuddyTR teşekkürler. Ufak bir araştırma sonucunda middleware yapilandirmasinin sarmal bir şekilde çalıştığını bir middleware'in başka bir middleware'i tetiklerken onun invoke metodunu çağırdıni ve her olusturulan middleware yapisinin icinde invoke metodunun olması gerektiğini farkettim. Ayrica recrusive mantıkta çalıştığından videoda bahsettiginiz next.Invoke() işleminin öncesindeki islemlerinin request, sonraki islemlerinin response sürecini kapsadığını kafamda daha net oturtmuş oldum.
middleware sayesinde CRUD işlemlerini ILOGGER da kaydedebilirmiyiz?
Tabi ki, ILogger ı kullanarak middleware içinde istediğimizi loglayabiliriz. Ama Crud işlemleri için efcore un savechanges metodu altında da logger kullanarak loglayabiliriz
Aspect mantığı ile mi Exceptin handling yapmak daha mantıklı yoksa middleware kullanarak mı yapmak daha mantıklı
Exception handle edildiğinde ne yapacağımızla da alakalı aslında bu un cevabı. Sadece exception oluştuşunda haberim olsun logumu basayım ama exception hayatına devam etsin dersek aspect daha mantıklı. Diğer yandan middleware içerisinde tüm süreci kendimiz kontrol edebiliyoruz. Response devam edecek mi etmeyecek mi ona kendimiz karar verebiliriz