Boş catch blokları neden kötü bir fikirdir? [kapalı]

Try-catch hakkında yeni bir soru gördüm , (Jon Skeet dahil) insanların boş catch bloklarının gerçekten kötü bir fikir olduğunu söyledikleri? Neden bu? Boş bir yakalamanın yanlış bir tasarım kararı olmadığı bir durum yok mu?

Örneğin, bazen, bir yerden (webservice, veritabanı) bazı ek bilgiler almak istersiniz ve bu bilgiyi alıp almayacağınızı gerçekten umursamıyorsunuz. Yani anlamaya çalışıyorsunuz ve bir şey olursa sorun değil, sadece bir "catch (istisna yoksayıldı) {}" ekleyeceğim ve hepsi bu

Genellikle boş try-catch kötü bir fikirdir, çünkü bir hata koşulunu sessizce yutuyor ve ardından uygulamaya devam ediyorsunuz. Bazen bu yapılması doğru olan şey olabilir, ancak genellikle bir geliştiricinin bir istisna gördüğünün, bu konuda ne yapacağını bilmediğinin ve bu nedenle sorunu susturmak için boş bir yakalama kullandığının bir işaretidir.

Motor uyarı ışığının üstüne siyah bant yerleştirmenin programlama eşdeğeri.

İstisnalarla nasıl başa çıkacağınızın yazılımın hangi katmanında çalıştığınıza bağlı olduğuna inanıyorum: Yağmur Ormanlarında İstisnalar .

Genel olarak kötü bir fikirdir , çünkü bir başarısızlığın (istisnai durum, daha genel olarak) NO cevabı ile düzgün bir şekilde karşılandığı gerçekten nadir bir durumdur. Bunun da catchötesinde , boş bloklar, istisnai motoru önleyici olarak yapmaları gerektiğini kontrol etmek için istisna motorunu kullanan kişiler tarafından kullanılan yaygın bir araçtır.

Her zaman kötü olduğunu söylemek yanlıştır ... bu çok az şey için doğrudur. Bir hatanın olmasını umursamanız ya da hatanın varlığının bir şekilde bu konuda hiçbir şey yapamayacağınızı gösterdiği durumlar olabilir (örneğin, bir metin günlük dosyasına önceki bir hatayı yazarken ve bir olsun IOExceptionsiz) yeni hata zaten dışarı yazamadım yani.

Boş catch blokları kullananların kötü bir programcı olduğunu ve ne yaptığını bilmediğini söyleyecek kadar uzamam ...

Gerekirse boş tutma blokları kullanıyorum. Bazen kullandığım kütüphane programcısı ne yaptığını bilmiyor ve kimsenin ihtiyacı olmadığı durumlarda bile istisnalar atıyor.

Örneğin, bazı http sunucu kitaplığını düşünün, istemcinin bağlantısı kesildiği ve index.htmlgönderilemediği için sunucu istisna atarsa ​​daha az umursamadım .

Gerekçe gösterilebilecek nadir durumlar vardır. Python'da genellikle bu tür bir inşaat görürsünüz:

try:
    result = foo()
except ValueError:
    result = None

Bu nedenle (uygulamanıza bağlı olarak) aşağıdakileri yapmak uygun olabilir:

result = bar()
if result == None:
    try:
        result = foo()
    except ValueError:
        pass # Python pass is equivalent to { } in curly-brace languages
 # Now result == None if bar() returned None *and* foo() failed

Son bir .NET projesinde, belirli bir arabirimi uygulayan sınıfları bulmak için eklenti DLL'leri numaralandırmak için kod yazmak zorunda kaldım. İlgili kod biti (VB.NET'te üzgünüm):

    For Each dllFile As String In dllFiles
        Try
            ' Try to load the DLL as a .NET Assembly
            Dim dll As Assembly = Assembly.LoadFile(dllFile)
            ' Loop through the classes in the DLL
            For Each cls As Type In dll.GetExportedTypes()
                ' Does this class implement the interface?
                If interfaceType.IsAssignableFrom(cls) Then

                    ' ... more code here ...

                End If
            Next
        Catch ex As Exception
            ' Unable to load the Assembly or enumerate types -- just ignore
        End Try
    Next

Bu durumda bile, hatayı bir yere kaydetmenin muhtemelen bir gelişme olacağını kabul ediyorum.

Boş yakalama blokları genellikle konur çünkü kodlayıcı ne yaptığını gerçekten bilmez. Kuruluşumda, boş bir catch bloğu, istisna ile hiçbir şey yapmamanın neden iyi bir fikir olduğuna dair bir yorum içermelidir.

İlgili bir notta, çoğu kişi {} bloğunun bir catch {} veya son olarak {} ile takip edilebileceğini bilmez, sadece bir tane gereklidir.

İstisnalar sadece gerçekten bir istisna varsa atılmalıdır - normların ötesinde bir şey oluyor. Boş bir catch bloğu temelde "kötü bir şey oluyor, ama umrumda değil" diyor. Bu kötü bir fikir.

Kural dışı durumu işlemek istemiyorsanız, işleyebilecek bir koda ulaşana kadar yukarı doğru yayılmasına izin verin. İstisna herhangi bir şeyle başa çıkamazsa, uygulamayı kaldırmalıdır.

Sadece belirli bir nedenden ötürü bunun yükseltileceğini bildiğiniz belirli bir istisna türünü yakalamanızın iyi olduğunu düşünüyorum ve bu istisnayı bekliyorsunuz ve gerçekten bu konuda bir şey yapmanız gerekmiyor.

Ancak bu durumda bile, bir hata ayıklama mesajı olabilir.

Başına Josh Bloch - Item 65: Do İstisnaları görmezden ait Etkili Java :

1. Boş bir catch bloğu istisnaların amacını yener
2. En azından catch bloğu, istisnayı görmezden gelmenin neden uygun olduğunu açıklayan bir yorum içermelidir.

Boş bir catch bloğu aslında "Hangi hataların atıldığını bilmek istemiyorum, sadece onları görmezden geleceğim" diyor.

VB6'lara benzer On Error Resume Next, ancak istisna atıldıktan sonra try bloğundaki herhangi bir şey atlanacaktır.

Bir şey kırıldığında yardımcı olmaz.

Bu, "Program akışını kontrol etmek için istisnalar kullanma" ve "Yalnızca istisnai durumlar için istisnalar kullanma" ile el ele gider. Bunlar yapılırsa, istisnalar sadece bir sorun olduğunda meydana gelmelidir. Ve bir sorun varsa, sessizce başarısız olmak istemezsiniz. Sorunu ele almanın gerekli olmadığı nadir anomalilerde, en azından istisnayı günlüğe kaydetmelisiniz, anomali artık bir anomali haline gelmezse. Başarısız olmaktan daha kötü olan tek şey sessizce başarısız olmaktır.

Tamamen boş bir catch bloğunun kötü bir fikir olduğunu düşünüyorum, çünkü istisnayı görmezden gelmenin kodun amaçlanan davranışı olduğunu çıkarmanın bir yolu yoktur. Bir istisnayı yutmak ve bazı durumlarda yanlış veya boş veya başka bir değer döndürmek her zaman kötü değildir. .Net çerçevesi, bu şekilde davranan birçok "try" yöntemine sahiptir. Kural dışı bir kural olarak, bir istisnayı yutarsanız, uygulama günlüğü destekliyorsa bir açıklama ve bir günlük ifadesi ekleyin.

Bir istisna Çünkü eğer bir sessizce başarısız olası en kötü seçenektir - - Eğer hatalı davranış ve yine oluyor görünümüne hiçbir fikri alırsınız Hiç görmez atılmış. En azından oraya bir günlük mesajı koy! 'Asla olmayacak' bir şey olsa bile!

Boş catch blokları, bir programcının bir istisna dışında ne yapacağını bilmediğinin bir göstergesidir. İstisnai olarak kabarmayı ve başka bir deneme bloğu tarafından doğru bir şekilde ele alınmasını önlüyorlar. Her zaman yakaladığınız istisna dışında bir şeyler yapmaya çalışın.

Boş catch ifadeleri ile en sinir bozucu bulmak başka bir programcı bunu yaptı. Demek istediğim, herhangi bir boş catch deyimi başka birinden kod hata ayıklamak gerektiğinde böyle bir girişim olması daha zor hale getirir. IMHO catch deyimleri her zaman bir tür hata mesajı göstermelidir - hata ele alınmasa bile en azından algılamalıdır (yalnızca hata ayıklama modunda)

Muhtemelen asla doğru olan şey değildir, çünkü olası her istisnayı sessizce geçiyorsunuz . Beklediğiniz özel bir istisna varsa, bunu test etmelisiniz, istisnanız değilse tekrar düşünün.

try
{
    // Do some processing.
}
catch (FileNotFound fnf)
{
    HandleFileNotFound(fnf);
}
catch (Exception e)
{
    if (!IsGenericButExpected(e))
        throw;
}

public bool IsGenericButExpected(Exception exception)
{
    var expected = false;
    if (exception.Message == "some expected message")
    {
        // Handle gracefully ... ie. log or something.
        expected = true;
    }

    return expected;
}

Genel olarak, yalnızca gerçekten başarabileceğiniz istisnaları yakalamanız gerekir. Bu, istisnaları yakalarken mümkün olduğunca spesifik olmak anlamına gelir. Tüm istisnaları yakalamak nadiren iyi bir fikirdir ve tüm istisnaları göz ardı etmek neredeyse her zaman çok kötü bir fikirdir.

Boş bir catch bloğunun anlamlı bir amacı olduğu birkaç örneği düşünebilirim. Belirli bir istisna ne olursa olsun, sadece eylemi yeniden denemekle yakalarsanız "ele alınır", yakalama bloğunda hiçbir şey yapmanıza gerek kalmaz. Bununla birlikte, istisnanın meydana geldiğini günlüğe kaydetmek iyi bir fikir olacaktır.

Başka bir örnek: CLR 2.0, sonlandırıcı diş üzerindeki işlenmemiş istisnaların işlenme şeklini değiştirdi. 2.0'dan önce bu senaryoda bu sürecin devam etmesine izin verildi. Mevcut CLR'de, sonlandırıcı diş üzerinde işlenmemiş bir istisna olması durumunda işlem sonlandırılır.

Bir sonlandırıcıyı yalnızca gerçekten ihtiyacınız varsa ve sonlandırıcıda mümkün olduğunca az yapmanız gerektiğini unutmayın. Ancak, sonlandırıcınızın yapması gereken her şey bir istisna oluşturabilirse, iki kötülükten daha azını seçmeniz gerekir. İşlenmeyen istisna nedeniyle uygulamayı kapatmak istiyor musunuz? Yoksa az çok tanımsız bir duruma geçmek mi istiyorsunuz? En azından teoride, ikincisi bazı durumlarda iki kötülükten daha az olabilir. Bu durumda, boş yakalama bloğu işlemin sonlandırılmasını engelleyecektir.

Örneğin, bazen, bir yerden (webservice, veritabanı) bazı ek bilgiler almak istersiniz ve bu bilgiyi alıp almayacağınızı gerçekten umursamıyorsunuz. Yani anlamaya çalışıyorsunuz ve bir şey olursa sorun değil, sadece bir "catch (istisna yoksayıldı) {}" ekleyeceğim ve hepsi bu

Örneğinize gitmek, bu durumda kötü bir fikir çünkü tüm istisnaları yakalayıp görmezden geliyorsunuz . Sadece yakalayıp EInfoFromIrrelevantSourceNotAvailablegörmezden gelseydin, bu iyi olurdu, ama değilsin. Ayrıca ENetworkIsDownönemli olabilir veya olmayabilir de görmezden geliyorsunuz . Sen görmezden geldiğin ENetworkCardHasMeltedve EFPUHasDecidedThatOnePlusOneIsSeventeenneredeyse kesinlikle önemli olan,.

Boş bir yakalama bloğu, yalnızca önemsiz olduğunu bildiğiniz belirli türdeki istisnaları yakalamak (ve yoksaymak) için ayarlanmışsa sorun değildir. Tüm istisnaları bastırmanın ve sessizce görmezden gelmenin iyi bir fikir olduğu durumlar, ilk önce beklenen / normal / alakasız olup olmadıklarını görmek için onları incelemeyi bırakmadan son derece nadirdir.

Bunları kullanabileceğiniz durumlar var, ancak çok seyrek olmalılar. Birini kullanabileceğim durumlar şunları içerir:

• istisna günlüğü; bağlama bağlı olarak bunun yerine işlenmeyen bir istisna veya mesaj gönderilmesini isteyebilirsiniz.

• oluşturma veya ses işleme veya bir liste kutusu geri çağırma gibi döngüsel teknik durumlar, davranışın kendisinin sorunu göstereceği, bir istisna atmanın sadece yoluna gireceği ve istisnanın kaydedilmesi muhtemelen 1000'lerin "XXX başarısız oldu" mesajlarıyla sonuçlanacaktır .

• en azından bir şey kaydediyor olsalar da başarısız olamayacak programlar .

çoğu winforms uygulamaları için, her kullanıcı girişi için tek bir try deyimi olması yeterli bulduk. Aşağıdaki yöntemleri kullanıyorum: (AlertBox sadece hızlı bir MessageBox.Show sarmalayıcıdır)

  public static bool TryAction(Action pAction)
  {
     try { pAction(); return true; }
     catch (Exception exception)
     {
        LogException(exception);
        return false;
     }
  }

  public static bool TryActionQuietly(Action pAction)
  {
     try { pAction(); return true; }
     catch(Exception exception)
     {
        LogExceptionQuietly(exception);
        return false;
     }
  }

  public static void LogException(Exception pException)
  {
     try
     {
        AlertBox(pException, true);
        LogExceptionQuietly(pException);
     }
     catch { }
  }

  public static void LogExceptionQuietly(Exception pException)
  {
     try { Debug.WriteLine("Exception: {0}", pException.Message); } catch { }
  }

Sonra her olay işleyicisi şöyle bir şey yapabilir:

  private void mCloseToolStripMenuItem_Click(object pSender, EventArgs pEventArgs)
  {
     EditorDefines.TryAction(Dispose);
  }

veya

  private void MainForm_Paint(object pSender, PaintEventArgs pEventArgs)
  {
     EditorDefines.TryActionQuietly(() => Render(pEventArgs));
  }

Teorik olarak, istisnaların sonsuz miktarda mesaj üretmemesi için çağrıları yapmak için daha iyi olabilecek TryActionSilently öğesine sahip olabilirsiniz.

Yakalama bloğunda ne yapacağınızı bilmiyorsanız, bu istisnayı kaydedebilirsiniz, ancak boş bırakmayın.

        try
        {
            string a = "125";
            int b = int.Parse(a);
        }
        catch (Exception ex)
        {
            Log.LogError(ex);
        }

Asla boş bir yakalama bloğunuz olmamalıdır. Bildiğiniz bir hatayı gizlemek gibidir. En azından zaman için basılırsa daha sonra incelemek için bir günlük dosyasına bir istisna yazmalısınız.