Yakalama kullanmak için özel olarak istisnalar oluşturma

if...elseKural dışı durum işleme ile sarılmış tipik bir örnek için, aşağıdaki örnek gibi bir şey kod çoğaltmasını önlemek için önerilen bir uygulama mıdır?

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        throw new Exception();
    }
catch(Exception ex)
{
    return null;
}

onun yerine...

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        return null;
    }
}
catch(Exception ex)
{
    return null;
}

Hafif bir performans isabeti olduğunu biliyorum, ancak bunun kabul edilebilir bir uygulama olarak kabul edilip edilmediğini merak ediyorum. Şu anda ikinci yöntemi yapıyorum - özellikle de belirli istisnaları farklı bir şekilde ele almam gereken durumlarda - ama ilk yöntemin basit durumlar için uygun olup olmadığını merak ediyordum.

Akış denetimi için özel durum işleme kullanımı Microsoft tarafından önerilmez.

Ve konuyla ilgili yuvarlak bir masa var.

Olduğu söyleniyor, C # bunu destekliyor ve bir istisna en uygun yanıt olup olmadığı karşılaşılan duruma bağlıdır varsayalım.

Bu cevapta açıklandığı gibi, performans isabeti büyük olasılıkla ihmal edilebilir .

Bu yüzden performansın bir sorun olmadığı fikrine geçelim. Sen atıyorlar System.Exception, sadece içine yürütülmesine taşımak için catchfıkra . A atmak BadControlFlowThatShouldBeRewrittenExceptionmuhtemelen aşırıya kaçmış olurdu.

Bunu parçalayalım. Sahibiz:

• Yöntem GetDataFromServer(yöntem adları C # içinde PascalCase olmalıdır) bool.
• Sonuç buysa true, çalıştırın ProcessData.
• nullAksi takdirde geri dönün .

Bu kodun yazıldığı yönteme benziyor, çok fazla şey yapıyor. GetDataFromServerBir dönen boolbir tasarım hatası gibi görünüyor, ben bu yöntemi bekliyor olurdu o sunucudan gidiyor veri döndürecek , bazı IEnumerable<SomeType>yani mutlu yol döner - 0 veya daha fazla öğe içerecektir n öğeleri n> 0 -so-mutlu değil, path 0 öğe döndürür ve mutsuz yol işlenmemiş bir istisna ile patlar, her neyse.

Bu, yöntemin görünüşünü çok değiştirir - yine bunun mantıklı olup olmadığını söylemek zordur, çünkü orijinal yazı sadece bir çıkış noktasına sahiptir (ve böylece tüm kod yolları bir değer döndürmediği için derlenmeyecektir ), bu sadece vahşi bir tahmin:

try
{
    var result = GetDataFromServer();
    return ProcessData(result);
}
catch
{
    return null;
}

Burada ProcessData, onun yinelendiğini görürsünüz resultve nullöğesinde hiçbir öğe yoksa geri döner IEnumerable.

Şimdi yöntem neden geri dönüyor null? Sunucu çöktü mü? Sorguda bir hata var mı? Bağlantı dizesi yanlış kimlik bilgilerini kullanıyor mu? Beklemediğiniz GetDataFromServerbir istisna ile patladığında, yutuyor, halının altına itiyor ve bir nulldeğer döndürüyorsunuz . Bu durumda belirli istisnaları yakalamanızı ve diğer her şeyi günlüğe kaydetmenizi öneririm; hata ayıklama bu şekilde çok daha kolay olacaktır.

catchİstisnayı yakalamayan genel bir maddeyle, hiçbir şeyi teşhis etmek oldukça zorlaşır. Bunun yerine minimal olarak yapardım:

catch(Exception e)
{
    return null;
}

Şimdi en azından bir eşeyler ters gidip gitmediğini inceleyebilir ve inceleyebilirsiniz .

TL; DR : Hayır, akış kontrolü için istisnalar atmak ve yakalamak iyi bir fikir değil.

ilk cevabınızda, orada olması gerekmeyen bir performans isabeti var.

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        throw new Exception();
    }
catch(Exception ex)
{
    return null;
}

if deyiminden çıktığınızda Catch deyimine girmek için kod değiştirme yönleri yapmanız gerekmediğinde, diyelim.

return null; bunu else deyiminden atıldıktan sonra yakalanan bir yakalamada değil else deyiminde yapmak istiyorsanız .

Muhtemelen Gerçek kodunuz için geçerli değildir , ancak verdiğiniz Genel kod için geçerlidir.

Standartlar bunu yapmamanız gerektiğini söylüyor.

Standartlar bunu böyle yapmanız gerektiğini söylüyor (yine OP'de verilen Genel Kod'a dayanarak)

if (GetDataFromServer())
{
    return ProcessData();
}
else
{
    Return null
}

ve yakaladığınız özel bir istisnanız olmadığından, burada bir deneme yakalamanız bile olmamalıdır.

İstisnalar oluştuğunda sorunu görmek için İstisnalar meydana geldiğinde görmek istersiniz.

Neden bu kadar basit değil:

if (!GetDataFromServer()) return null;
ProcessData();

Bir istisna işleyici mevcut olacaksa, bu işlem ProcessData () içinde olmalıdır