Deneme / Yakalama / Günlük / Tekrar Et - Anti Desen mi?

Merkezi konumda veya süreç sınırında istisna işlemenin öneminin denemek / yakalamak etrafında her kod bloğunu çöp yerine iyi bir uygulama olarak vurgulandığı birkaç yazı görebiliyorum. Çoğumuzun önemini anladığımıza inanıyorum, ancak insanların genellikle herhangi bir istisna sırasında sorun gidermeyi kolaylaştırmak için catch-log-rethrow anti modeliyle son bulduklarını görüyorum. geçti) ve yol, try / catch / log / rethrow yöntemini sarmaktır.

public static bool DoOperation(int num1, int num2)
{
    try
    {
        /* do some work with num1 and num2 */
    }
    catch (Exception ex)
    {
        logger.log("error occured while number 1 = {num1} and number 2 = {num2}"); 
        throw;
    }
}

İstisna yönetimi iyi uygulamalarını sürdürürken bunu başarmanın doğru yolu var mı? Bunun için PostSharp gibi AOP çerçevesini duydum, ancak bu AOP çerçeveleriyle ilişkili herhangi bir olumsuz veya büyük performans maliyeti olup olmadığını bilmek istiyorum.

Teşekkürler!

Sorun yerel catch bloğu değil, sorun log ve rethrow . İstisnayı ele alın veya ek bağlam ekleyen yeni bir istisna ile sarın ve atın. Aksi takdirde, aynı istisna için birkaç yinelenen günlük girişi ile karşılaşacaksınız.

Buradaki fikir , uygulamanızda hata ayıklama yeteneğini geliştirmektir .

Örnek 1 - Ele alın

try
{
    doSomething();
}
catch (Exception e)
{
    log.Info("Couldn't do something", e);
    doSomethingElse();
}

Kural dışı durumu ele alırsanız, kural dışı durum günlüğü girdisinin önemini kolayca azaltabilirsiniz ve bu kural dışı durumu zincirlemek için bir neden yoktur. Zaten halledildi.

Bir istisnayı ele almak, kullanıcılara bir sorunun olduğunu bildirmeyi, olayı günlüğe kaydetmeyi veya basitçe yok saymayı içerebilir.

NOT: Bir istisnayı kasıtlı olarak yoksayarsanız, boş catch yan tümcesinde bunun nedenini açıkça belirten bir yorum sağlamanızı öneririm. Bu, gelecekteki bakıcıların bunun bir hata veya tembel programlama olmadığını bilmelerini sağlar. Misal:

try
{
    context.DrawLine(x1,y1, x2,y2);
}
catch (OutOfMemoryException)
{
    // WinForms throws OutOfMemory if the figure you are attempting to
    // draw takes up less than one pixel (true story)
}

2. Örnek: Ek bağlam ekleyin ve atın

try
{
    doSomething(line);
}
catch (Exception e)
{
    throw new MyApplicationException(filename, line, e);
}

Ek bağlam eklemek (ayrıştırma kodundaki satır numarası ve dosya adı gibi), giriş dosyalarında hata ayıklama yeteneğini geliştirmeye yardımcı olabilir - sorunun orada olduğu varsayılarak. Bu bir tür özel durumdur, bu nedenle "ApplicationException" içinde bir istisnayı yeniden paketlemek yalnızca hata ayıklamanıza yardımcı olmaz. Ek bilgi eklediğinizden emin olun.

Örnek 3: İstisna dışında hiçbir şey yapmayın

try
{
    doSomething();
}
finally
{
   // cleanup resources but let the exception percolate
}

Bu son durumda, istisnanın dokunmadan ayrılmasına izin verirsiniz. En dış katmandaki özel durum işleyici, günlüğe kaydetmeyi işleyebilir. finallyFıkra kadar temizlenir sizin yöntemiyle gerekli emin tüm kaynakları yapmak için kullanılan, ancak bu istisna atıldı oturum açmak için yer değildir.

Yerel yakalamaların bir anti-desen olduğuna inanmıyorum, aslında doğru hatırlıyorsam aslında Java'da zorlanıyor!

Hata işlemeyi uygularken benim için kilit nokta genel stratejidir. Servis sınırındaki tüm istisnaları yakalayan bir filtre isteyebilirsiniz, bunları manuel olarak ele almak isteyebilirsiniz - her ikisi de, takımlarınızın kodlama standartlarına girecek genel bir strateji olduğu sürece iyidir.

Şahsen ben aşağıdakilerden birini yapabildiğimde bir fonksiyon içindeki hataları yakalamak istiyorum:

• Bağlamsal bilgiler ekleyin (nesnelerin durumu veya olan bitenler gibi)
• Kural dışı durumu güvenli bir şekilde yönetme (TryX yöntemi gibi)
• Sisteminiz bir hizmet sınırını aşıyor ve harici bir kitaplığa veya API'ya çağrı yapıyor
• Farklı bir istisna türünü yakalamak ve yeniden düzenlemek istersiniz (belki orijinali bir iç istisna olarak)
• İstisna, bazı düşük değerli arka plan işlevlerinin bir parçası olarak atıldı

Bu durumlardan biri değilse, yerel bir try / catch eklemem. Öyleyse, senaryoya bağlı olarak istisnayı (örneğin, yanlış döndüren bir TryX yöntemi) işleyebilir veya istisna genel strateji tarafından ele alınabilir.

Örneğin:

public bool TryConnectToDatabase()
{
  try
  {
    this.ConnectToDatabase(_databaseType); // this method will throw if it fails to connect
    return true;
  }
  catch(Exception ex)
  {
     this.Logger.Error(ex, "There was an error connecting to the database, the databaseType was {0}", _databaseType);
    return false;
  }
}

Veya yeniden inceleme örneği:

public IDbConnection ConnectToDatabase()
{
  try
  {
    // connect to the database and return the connection, will throw if the connection cannot be made
  }
  catch(Exception ex)
  {
     this.Logger.Error(ex, "There was an error connecting to the database, the databaseType was {0}", _databaseType);
    throw;
  }
}

Sonra yığının üstündeki hatayı yakalar ve kullanıcıya hoş bir kullanıcı dostu mesaj sunar.

Hangi yaklaşımı kullanırsanız kullanın, bu senaryolar için daima birim testleri oluşturmaya değer; böylece işlevin daha sonraki bir tarihte projenin akışını değiştirmediğinden ve akışını bozmadığından emin olabilirsiniz.

Hangi dilde çalıştığınızdan bahsetmediniz, ancak bir .NET geliştiricisi olduğunuzu ve bunu birçok kez görmediğinizi gördünüz.

YAZMA:

catch(Exception ex)
{
  throw ex;
}

kullanın:

catch(Exception ex)
{
  throw;
}

Birincisi yığın izini sıfırlar ve en üst seviyenizi tamamen işe yaramaz hale getirir!

TLDR

Yerel olarak yakalamak bir anti-desen değildir, genellikle bir tasarımın parçası olabilir ve hataya ek bağlam eklemeye yardımcı olabilir.

Bu büyük ölçüde dile bağlıdır. Örneğin, C ++ istisna hata mesajlarında yığın izleri sunmaz, bu nedenle istisnaları sık sık yakalama-log-rethrow ile izlemek faydalı olabilir. Buna karşılık, Java ve benzer diller çok iyi yığın izleri sunar, ancak bu yığın izlerinin biçimi çok yapılandırılamayabilir. Gerçekten önemli bir bağlam ekleyemediğiniz sürece (örn. Bir alt düzey SQL istisnasını bir iş mantığı işlemi bağlamıyla bağlama) bu dillerdeki istisnaları yakalamak ve yeniden düzenlemek tamamen anlamsızdır.

Yansıtma yoluyla uygulanan herhangi bir hata işleme stratejisi, dilde yerleşik işlevlerden neredeyse daha az verimlidir. Ayrıca, yaygın günlük kaydı kaçınılmaz performans yüküne sahiptir. Bu nedenle, bu yazılım için diğer gereksinimlerle elde ettiğiniz bilgi akışını dengelemeniz gerekir. Bununla birlikte, derleyici düzeyinde enstrümantasyon üzerine inşa edilen PostSharp gibi çözümler genellikle çalışma zamanı yansımasından çok daha iyi sonuç verecektir.

Şahsen her şeyin günlüğe kaydedilmesinin yararlı olmadığına inanıyorum, çünkü bir sürü alakasız bilgi içeriyor. Bu nedenle otomatik çözümlere şüpheliyim. İyi bir günlük kaydı çerçevesi göz önüne alındığında, ne tür bilgileri kaydetmek istediğinizi ve bu bilgilerin nasıl biçimlendirilmesi gerektiğini tartışan üzerinde anlaşmaya varılmış bir kodlama kılavuzuna sahip olmak yeterli olabilir. Ardından, önemli olduğu yerde günlük kaydı ekleyebilirsiniz.

İş mantığında oturum açmak, yardımcı program işlevlerinde oturum açmaktan çok daha önemlidir. Ve gerçek dünya kilitlenme raporlarının yığın izlerini toplamak (yalnızca bir işlemin en üst düzeyinde günlüğe kaydetmeyi gerektirir) kodun günlüğe kaydetmenin en değerli olacağı alanları bulmanızı sağlar.

try/catch/logHer yöntemde gördüğümde , geliştiricilerin uygulamalarında ne olabileceği veya olmayabileceği hakkında hiçbir fikre sahip olmadıkları, en kötüsünü aldıkları ve bekledikleri tüm hatalar nedeniyle her yerde önleyici olarak her şeyi kaydettikleri endişeleri ortaya çıkıyor.

Bu, birim ve entegrasyon testlerinin yetersiz olduğunu ve geliştiricilerin hata ayıklayıcıdaki çok sayıda koddan geçmeye alışık olduklarını ve bir sürü günlük kaydının, buggy kodunu bir test ortamında dağıtmalarına ve sorunlara bakarak bulmalarını umduklarını gösteren bir belirtidir. günlükleri.

Kod atar istisnalar gereksiz kod o yakalar ve günlükleri istisnalar daha yararlı olabilir. Bir yöntem beklenmedik bir argüman aldığında anlamlı bir mesajla bir istisna atarsanız (ve hizmet sınırında günlüğe kaydederseniz), geçersiz argümanın bir yan etkisi olarak atılan istisnayı hemen günlüğe kaydetmekten ve buna neden olduğunu tahmin etmekten çok daha yararlıdır. .

Sıfırlar buna bir örnektir. Bağımsız değişken veya yöntem çağrısının sonucu olarak bir değer alırsanız ve bu değerin boş olmaması gerekiyorsa, istisnayı atın. NullReferenceExceptionNull değeri nedeniyle sonuçta atılan beş satırı daha sonra günlüğe kaydetmeyin. Her iki durumda da bir istisna alırsınız, ancak biri size bir şey söylerken, diğeri sizi bir şey aramanızı sağlar.

Başkaları tarafından söylendiği gibi, istisnaları hizmet sınırında veya bir istisna yeniden gözden geçirilmediğinde günlüğe kaydedildiği için günlüğe kaydetmek en iyisidir. En önemli fark bir şeyle hiçbir şey arasındadır. İstisnalarınız kolayca ulaşılabilecek tek bir yere kaydedilirse, ihtiyacınız olan bilgileri ihtiyacınız olduğunda bulabilirsiniz.

Zaten istisna dışında olmayan bağlam bilgilerini kaydetmeniz gerekiyorsa, bunu yeni bir istisnaya sarın ve orijinal istisnayı olarak sağlayın InnerException. Bu şekilde orijinal yığın izini koruyabilirsiniz. Yani:

public static bool DoOperation(int num1, int num2)
{
    try
    {
        /* do some work with num1 and num2 */
    }
    catch (Exception ex)
    {
        throw new Exception("error occured while number 1 = {num1} and number 2 = {num2}", ex);
    }
}

Yapıcıya ikinci parametre Exceptionbir iç istisna sağlar. Daha sonra tüm istisnaları tek bir yerde kaydedebilirsiniz ve yine de tüm yığın izlemesini ve bağlamsal bilgileri aynı günlük girişinde alabilirsiniz.

Özel bir istisna sınıfı kullanmak isteyebilirsiniz, ancak nokta aynı.

kafa karıştırıcı günlüklere yol açacağı için denemek / yakalamak / log / rethrow bir karışıklıktır - örneğin, bağlamsal bilgilerin kaydedilmesi ile asıl istisnanın üstündeki gerçek istisnaların kaydedilmesi arasında başka bir iş parçacığında farklı bir istisna olursa ne olur? Yeni istisna orijinal belgeye bilgi eklerse try / catch / throw gayet iyi.

İstisnanın kendisi, mesaj, hata kodu ve ne dahil olmak üzere uygun günlük kaydı için gerekli tüm bilgileri sağlamalıdır. Bu nedenle, yalnızca yeniden değerlendirmek veya farklı bir istisna atmak için bir istisna yakalamaya gerek yoktur.

Genellikle, DatabaseConnectionException'ı, InvalidQueryException'ı ve InvalidSQLParameterException'ı yakalamak ve bir DatabaseException'ı yeniden yazmak gibi yaygın bir istisna olarak yakalanan ve yeniden oluşturulan birkaç özel durum modelini görürsünüz. Buna rağmen, tüm bu özel istisnaların ilk olarak DatabaseException'dan türetilmesi gerektiğini savunuyorum, bu yüzden yeniden düzenleme gerekli değildir.

Gereksiz deneme yakalama hükümlerinin kaldırılmasının (yalnızca günlük kayıt amacıyla kullanılanlar için bile) işi daha kolay değil, daha kolay hale getireceğini göreceksiniz. Yalnızca programınızdaki özel durumu işleyen yerler özel durumu günlüğe kaydetmelidir ve diğer her şey başarısız olursa, programdan zarif bir şekilde çıkmadan önce özel durumu günlüğe kaydetmeye yönelik son bir girişim için program çapında bir özel durum işleyicisi. Kural dışı durum, kural dışı durumun atıldığı noktayı gösteren tam bir yığın izine sahip olmalıdır, bu nedenle genellikle "bağlam" günlüğü sağlamak gerekli değildir.

Bu, AOP'nin sizin için hızlı bir çözüm olabileceğini, ancak genel olarak hafif bir yavaşlama gerektirdiğini söyledi. Bunun yerine, hiçbir değerin eklenmediği yerdeki gereksiz deneme yakalama maddelerini tamamen kaldırmanızı öneririm.