.NET istisnalarını yakalamak ve yeniden atmak için en iyi uygulamalar

İstisnaları yakalayıp yeniden atarken dikkate alınması gereken en iyi uygulamalar nelerdir? ExceptionNesnenin InnerExceptionve yığın izlemesinin korunduğundan emin olmak istiyorum . Aşağıdaki kod blokları arasında, bunların işlenme biçiminde bir fark var mı?

try
{
    //some code
}
catch (Exception ex)
{
    throw ex;
}

Vs:

try
{
    //some code
}
catch
{
    throw;
}

Yığın izini korumanın yolu, throw;Bu da geçerlidir.

try {
  // something that bombs here
} catch (Exception ex)
{
    throw;
}

throw ex;temelde bu noktadan bir istisna atmak gibidir, bu nedenle yığın izlemesi yalnızca throw ex;ifadeyi yayınladığınız yere gider .

Mike da doğrudur, istisnanın bir istisna geçirmenize izin verdiği varsayılarak (önerilir).

Karl Seguin bir sahiptir taşıma istisna kadar büyük bir yazma onun içinde e-kitap programlama temelleri büyük bir okuma yanı sıra, hangi.

Düzenle: Programlamanın Temelleri çalışma pdf. Metinde "istisna" ifadesini aramanız yeterlidir.

İlk istisna ile yeni bir istisna atarsanız, ilk yığın izini de koruyacaksınız.

try{
} 
catch(Exception ex){
     throw new MoreDescriptiveException("here is what was happening", ex);
}

Aslında, throwifadenin StackTrace bilgilerini korumayacağı bazı durumlar vardır . Örneğin, aşağıdaki kodda:

try
{
  int i = 0;
  int j = 12 / i; // Line 47
  int k = j + 1;
}
catch
{
  // do something
  // ...
  throw; // Line 54
}

StackTrace, satır 47'de yükseltilmesine rağmen, satır 54'ün istisnayı yükselttiğini gösterecektir.

Unhandled Exception: System.DivideByZeroException: Attempted to divide by zero.
   at Program.WithThrowIncomplete() in Program.cs:line 54
   at Program.Main(String[] args) in Program.cs:line 106

Yukarıda açıklananlara benzer durumlarda, orijinal StackTrace'i sunmak için iki seçenek vardır:

İstisna Çağırma.InternalPreserveStackTrace

Özel bir yöntem olduğundan, yansıma kullanılarak çağrılmalıdır:

private static void PreserveStackTrace(Exception exception)
{
  MethodInfo preserveStackTrace = typeof(Exception).GetMethod("InternalPreserveStackTrace",
    BindingFlags.Instance | BindingFlags.NonPublic);
  preserveStackTrace.Invoke(exception, null);
}

StackTrace bilgilerini korumak için özel bir yönteme güvenmek dezavantajı var. .NET Framework'ün gelecekteki sürümlerinde değiştirilebilir. Yukarıdaki kod örneği ve aşağıda önerilen çözüm Fabrice MARGUERIE weblogundan alınmıştır .

Callception Exception.SetObjectData

Aşağıdaki teknik Anton Tykhyy tarafından C # 'a yanıt olarak önerildi , yığın izleme sorusunu kaybetmeden InnerException'ı nasıl yeniden arayabilirim .

static void PreserveStackTrace (Exception e) 
{ 
  var ctx = new StreamingContext  (StreamingContextStates.CrossAppDomain) ; 
  var mgr = new ObjectManager     (null, ctx) ; 
  var si  = new SerializationInfo (e.GetType (), new FormatterConverter ()) ; 

  e.GetObjectData    (si, ctx)  ; 
  mgr.RegisterObject (e, 1, si) ; // prepare for SetObjectData 
  mgr.DoFixups       ()         ; // ObjectManager calls SetObjectData 

  // voila, e is unmodified save for _remoteStackTraceString 
} 

Her ne kadar kamu yöntemlerine güvenme avantajına sahip olsa da, sadece aşağıdaki istisna kurucusuna da bağlıdır (üçüncü taraflarca geliştirilen bazı istisnalar geçerli değildir):

protected Exception(
    SerializationInfo info,
    StreamingContext context
)

Benim durumumda, ilk yaklaşımı seçmek zorunda kaldım, çünkü kullandığım üçüncü taraf bir kütüphane tarafından ortaya konan istisnalar bu yapıcıyı uygulamadı.

Siz throw ex, aslında yeni bir istisna atarsınız ve orijinal yığın izleme bilgilerini kaçırırsınız. throwtercih edilen yöntemdir.

Temel kural, temel Exceptionnesneyi yakalamak ve atmaktan kaçınmaktır . Bu sizi istisnalar konusunda biraz daha akıllı olmaya zorlar; başka bir deyişle SqlException, işleme kodunuzun a ile yanlış bir şey yapmaması için açık bir yakalamanız olmalıdır NullReferenceException.

Yine de gerçek dünyada , temel istisnayı yakalamak ve günlüğe kaydetmek de iyi bir uygulamadır, ancak InnerExceptionssahip olabileceği her şeyi elde etmek için her şeyi yürümeyi unutmayın .

Her zaman "atış" kullanmalısınız. .NET'teki istisnaları yeniden yazmak,

Buna bakın, http://weblogs.asp.net/bhouse/archive/2004/11/30/272297.aspx

Temel olarak MSIL (CIL) 'in iki talimatı vardır: "fırlat" ve "tekrar":

• C # 's "atmak eski;" MSIL'in "atış" ına derlendi
• C # 's "atmak;" - MSIL "yeniden" içine!

Temelde "ex ex atın" yığın izini geçersiz kılma nedenini görebiliyorum.

Kimse ile ExceptionDispatchInfo.Capture( ex ).Throw()ova arasındaki farkı açıklamadı throw, işte burada. Ancak, bazı insanlar sorunu fark ettiler throw.

Yakalanan bir istisnayı yeniden anlatmanın tam yolu kullanmaktır ExceptionDispatchInfo.Capture( ex ).Throw()(yalnızca .Net 4.5'ten edinilebilir).

Aşağıda bunu test etmek için gerekli durumlar vardır:

1.

void CallingMethod()
{
    //try
    {
        throw new Exception( "TEST" );
    }
    //catch
    {
    //    throw;
    }
}

2.

void CallingMethod()
{
    try
    {
        throw new Exception( "TEST" );
    }
    catch( Exception ex )
    {
        ExceptionDispatchInfo.Capture( ex ).Throw();
        throw; // So the compiler doesn't complain about methods which don't either return or throw.
    }
}

3.

void CallingMethod()
{
    try
    {
        throw new Exception( "TEST" );
    }
    catch
    {
        throw;
    }
}

4.

void CallingMethod()
{
    try
    {
        throw new Exception( "TEST" );
    }
    catch( Exception ex )
    {
        throw new Exception( "RETHROW", ex );
    }
}

Durum 1 ve durum 2, CallingMethodyöntemin kaynak kodu satır numarasının satırın satır numarası olduğu bir yığın izlemesi verecektir throw new Exception( "TEST" ).

Ancak, 3. durum size CallingMethodyöntemin kaynak kodu satır numarasının throwçağrının hat numarası olduğu bir yığın izlemesi verecektir . Bu, throw new Exception( "TEST" )çizgi diğer işlemlerle çevriliyse, istisnanın hangi satır numarasına atıldığına dair hiçbir fikriniz olmadığı anlamına gelir .

Durum 4, durum 2 ile benzerdir, çünkü orijinal istisnanın satır numarası korunur, ancak orijinal istisnanın türünü değiştirdiği için gerçek bir tekrarlama değildir.

Birkaç kişi gerçekten çok önemli bir noktayı kaçırdı - 'atmak' ve 'eski atmak' aynı şeyi yapabilir, ancak size istisnanın gerçekleştiği çizgi olan önemli bir imformasyon parçası vermezler.

Aşağıdaki kodu göz önünde bulundurun:

static void Main(string[] args)
{
    try
    {
        TestMe();
    }
    catch (Exception ex)
    {
        string ss = ex.ToString();
    }
}

static void TestMe()
{
    try
    {
        //here's some code that will generate an exception - line #17
    }
    catch (Exception ex)
    {
        //throw new ApplicationException(ex.ToString());
        throw ex; // line# 22
    }
}

'Atma' veya 'atma' yaptığınızda yığın izini alırsınız, ancak # satırı # 22 olur, böylece hangi satırın istisnayı tam olarak attığını anlayamazsınız (yalnızca 1 veya birkaçınız yoksa try bloğundaki kod satırları). İstisnadaki # 17 numaralı satırı elde etmek için orijinal istisna yığını izlemesine yeni bir istisna atmanız gerekir.

Ayrıca şunları kullanabilirsiniz:

try
{
// Dangerous code
}
finally
{
// clean up, or do nothing
}

Ve atılan herhangi bir istisna, onları işleyen bir sonraki seviyeye yükselecektir.

Kesinlikle kullanacağım:

try
{
    //some code
}
catch
{
    //you should totally do something here, but feel free to rethrow
    //if you need to send the exception up the stack.
    throw;
}

Bu yığınızı koruyacaktır.

FYI Bunu sadece test ettim ve yığın izlemesi 'throw;' tamamen doğru bir yığın izlemesi değildir. Misal:

    private void foo()
    {
        try
        {
            bar(3);
            bar(2);
            bar(1);
            bar(0);
        }
        catch(DivideByZeroException)
        {
            //log message and rethrow...
            throw;
        }
    }

    private void bar(int b)
    {
        int a = 1;
        int c = a/b;  // Generate divide by zero exception.
    }

Yığın izi, istisnanın kökenini doğru bir şekilde gösterir (rapor edilen satır numarası), ancak foo () için rapor edilen satır numarası fırlatma çizgisidir; ifadesi ile bar () çağrılarından hangisinin istisnaya neden olduğunu söyleyemezsiniz.