"Log and throw" neden anti-model olarak kabul edilir? [kapalı]

Bu soru, hiçbir iyi yanıt alamadığım bu makale etrafında bir tartışma ile ateşlendi.

Aksi halde üstesinden gelemiyorsanız neden istisnanızı günlüğe kaydetmek ve sonra yeniden atmak (tabii ki orijinal yığın izini korumak) kötü bir fikir olsun?

Sanırım cevabın büyük ölçüde üstesinden gelemiyorsan neden yakalıyorsun? Günlüğe layık olduğunu hissediyorlarsa, neden başa çıkabilecek (ya da başka seçeneği kalmayanların) günlüğe kaydetmesine izin vermiyorlar?

Onu yakalar ve günlüğe kaydedip yeniden atarsanız, yukarı akış kodunun istisnayı zaten kaydettiğinizi bilmesinin bir yolu yoktur ve bu nedenle aynı istisna iki kez günlüğe kaydedilebilir. Daha da kötüsü, tüm yukarı akış kodu aynı modeli takip ederse, istisna, onu yakalamaya, günlüğe kaydetmeye ve ardından tekrar atmaya karar veren koddaki her düzey için bir kez olmak üzere, rastgele bir sayıda günlüğe kaydedilebilir.

Ayrıca bazıları, istisnaları atma ve yakalama görece maliyetli işlemler olduğundan, tüm bu yakalama ve yeniden fırlatma işlemlerinin çalışma zamanı performansınıza yardımcı olmadığını iddia edebilir. Ne de özlü veya sürdürülebilirlik açısından kodunuza yardımcı olmaz.

Log-and-throw, istisnayı yakalayan ve yeniden atan varlığın, bunun çağrı yığınında daha fazla günlüğe kaydedilmeyecek bilgiler içerdiğine inanmak için bir nedeni varsa - en azından en çok istenen biçimde değil - iyi bir modeldir. Bunun meydana gelmesinin birkaç nedeni:

1. İstisna, bir uygulama katmanı sınırında yakalanabilir ve yeniden atılabilir ve ayrıcalıklı bilgiler içerebilir. Bir veritabanı katmanının, dış uygulama katmanına erişmek için "kullanıcılar" alanına yinelenen anahtar 'fnord' eklemeye çalışın gibi bir istisnaya izin vermesi kötü olur (bu da bir kullanıcıya ifşa edebilir), ancak Veritabanının iç kısımlarının böyle bir istisna atması ve uygulama arayüzünün onu yakalaması, güvenli bir şekilde günlüğe kaydetmesi ve biraz daha az açıklayıcı bir istisnayı yeniden atması için yararlı olabilir.
2. Bunun istisnası, dış katmanın büyük olasılıkla kayıt olmadan işlemeyi beklediği bir durum olabilir, ancak iç katman, dış katmanın bilmediği bir şeyi bilebilir ve bu da günlüğe kaydetmenin yararlı olabileceğini düşündürür. Kaba bir örnek olarak, bir orta uygulama katmanı bir sunucuya bağlanmayı denemek için programlanabilir ve bu işe yaramazsa başka birini deneyebilir. Bir sunucu bakım için kapalıyken uygulamanın günlüğünü 'bağlantı başarısız' mesajlarıyla doldurmak, özellikle uygulamanın bakış açısına göre her şey yolunda gittiği için yararlı olmayabilir. Her bir bağlantı girişiminin günlüğü yerine sunucunun ne zaman yukarı ve aşağı gittiğine dair bir rapor oluşturmak için daha sonra günlükleri filtreleyebilen sunucularla ilişkili bir günlük kaynağına bağlantı hatası hakkındaki bilgileri iletmek yararlı olabilir. .

Sanırım en basit neden, bunu sizin için yapan tek bir üst düzey işleyiciye sahip olmanızdır, bu nedenle bu istisna işleme ile kodu kirletmenize gerek yoktur.

Kesişen endişeler argümanı temelde sizi ilgilendirmeyen hataları ele almak için zaman kaybı olduğudur. Uygun bir işleyici bulunana kadar hatanın çağrı yığınını yukarı kaldırmasına izin vermek çok daha iyidir.

Kanımca, bir istisna yakalamanız gereken tek zaman, sonuçlarla faydalı bir şeyler yapabileceğiniz zamandır. Basitçe günlüğe kaydetmek için yakalamak yararlı değildir, çünkü bu işi daha da merkezileştirebilirsiniz.

IMO günlüğü ve fırlatma, En Az Sürpriz Prensibinin açık bir ihlalidir.

İstisna, çağrı yığınının yukarısında düzgün bir şekilde işlenirse, bir hata günlüğü girişi hiç değmeyebilir. Ve sonra bir hata günlüğü girişi bulmak kafa karıştırıcı.