Praktik terbaik untuk menangkap dan melempar kembali .NET pengecualian

Apa praktik terbaik yang harus dipertimbangkan ketika menangkap pengecualian dan melemparkannya kembali? Saya ingin memastikan bahwa jejak Exceptionobjek InnerExceptiondan tumpukan dipertahankan. Apakah ada perbedaan antara blok kode berikut dalam cara mereka menangani ini?

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

Vs:

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

Cara untuk melestarikan jejak tumpukan adalah melalui penggunaan throw;Ini juga berlaku

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

throw ex;pada dasarnya seperti melempar pengecualian dari titik itu, jadi jejak tumpukan hanya akan pergi ke tempat Anda mengeluarkan throw ex;pernyataan.

Mike juga benar, dengan asumsi pengecualian memungkinkan Anda untuk melewati pengecualian (yang disarankan).

Karl Seguin memiliki tulisan yang bagus tentang penanganan pengecualian dalam fondasinya pemrograman e-book juga, yang merupakan bacaan yang bagus.

Sunting: Tautan yang berfungsi ke Yayasan Pemrograman pdf. Cukup cari teks untuk "pengecualian".

Jika Anda melempar pengecualian baru dengan pengecualian awal, Anda juga akan mempertahankan jejak tumpukan awal ..

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

Sebenarnya, ada beberapa situasi dimana throwstatment tidak akan menyimpan informasi StackTrace. Misalnya, dalam kode di bawah ini:

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

StackTrace akan menunjukkan bahwa baris 54 menaikkan pengecualian, meskipun itu dinaikkan pada baris 47.

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

Dalam situasi seperti yang dijelaskan di atas, ada dua opsi untuk preseve StackTrace asli:

Memanggil Exception.InternalPreserveStackTrace

Karena ini adalah metode pribadi, itu harus dipanggil dengan menggunakan refleksi:

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

Saya memiliki kelemahan mengandalkan metode pribadi untuk menjaga informasi StackTrace. Itu bisa diubah di versi .NET Framework. Contoh kode di atas dan solusi yang diusulkan di bawah ini diambil dari weblog Fabrice MARGUERIE .

Memanggil Exception.SetObjectData

Teknik di bawah ini disarankan oleh Anton Tykhyy sebagai jawaban untuk In C #, bagaimana saya bisa memikirkan kembali InnerException tanpa kehilangan pertanyaan susunan jejak .

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 
} 

Meskipun, memiliki keuntungan mengandalkan metode publik hanya itu juga tergantung pada konstruktor pengecualian berikut (yang beberapa pengecualian yang dikembangkan oleh pihak ke-3 tidak diterapkan):

protected Exception(
    SerializationInfo info,
    StreamingContext context
)

Dalam situasi saya, saya harus memilih pendekatan pertama, karena pengecualian yang diajukan oleh perpustakaan pihak ketiga yang saya gunakan tidak menerapkan konstruktor ini.

Saat Anda throw ex, Anda pada dasarnya melempar pengecualian baru, dan akan kehilangan informasi tumpukan jejak yang asli. throwadalah metode yang disukai.

Aturan praktisnya adalah untuk menghindari Catching and Throwing the basic Exceptionobject. Ini memaksa Anda untuk menjadi sedikit lebih pintar tentang pengecualian; dengan kata lain Anda harus memiliki tangkapan eksplisit untuk SqlExceptionkode penanganan Anda sehingga tidak melakukan sesuatu yang salah dengan a NullReferenceException.

Namun di dunia nyata, menangkap dan mencatat pengecualian basis juga merupakan praktik yang baik, tetapi jangan lupa untuk melakukan semuanya untuk mendapatkan apa InnerExceptionsyang mungkin ada.

Anda harus selalu menggunakan "lemparan;" untuk memikirkan kembali pengecualian di .NET,

Lihat ini, http://weblogs.asp.net/bhouse/archive/2004/11/30/272297.aspx

Pada dasarnya MSIL (CIL) memiliki dua instruksi - "melempar" dan "rethrow":

• "Throw ex;" akan dikompilasi ke dalam "lemparan" MSIL
• "Lemparan;" - ke dalam MSIL "rethrow"!

Pada dasarnya saya dapat melihat alasan mengapa "throw ex" menimpa jejak stack.

Tidak ada yang menjelaskan perbedaan antara ExceptionDispatchInfo.Capture( ex ).Throw()dan dataran throw, jadi ini dia. Namun, beberapa orang telah memperhatikan masalah tersebut throw.

Cara lengkap untuk mengubah kembali pengecualian yang tertangkap adalah menggunakan ExceptionDispatchInfo.Capture( ex ).Throw()(hanya tersedia dari .Net 4.5).

Di bawah ini ada kasus yang diperlukan untuk menguji ini:

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 );
    }
}

Kasus 1 dan kasus 2 akan memberi Anda jejak tumpukan di mana nomor baris kode sumber untuk CallingMethod metode ini adalah nomor baris dari throw new Exception( "TEST" )baris tersebut.

Namun, kasus 3 akan memberi Anda jejak tumpukan di mana nomor baris kode sumber untuk CallingMethodmetode ini adalah nomor baristhrow panggilan. Ini berarti bahwa jika throw new Exception( "TEST" )garis dikelilingi oleh operasi lain, Anda tidak tahu di mana nomor garis pengecualian itu sebenarnya dilemparkan.

Kasus 4 mirip dengan kasus 2 karena nomor baris pengecualian asli dipertahankan, tetapi bukan rethrow nyata karena mengubah jenis pengecualian asli.

Beberapa orang benar-benar melewatkan poin yang sangat penting - 'melempar' dan 'melempar mantan' mungkin melakukan hal yang sama tetapi mereka tidak memberi Anda sepotong penting informasi yang merupakan garis di mana pengecualian terjadi.

Pertimbangkan kode berikut:

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
    }
}

Ketika Anda melakukan 'melempar' atau 'melempar mantan' Anda mendapatkan jejak tumpukan tetapi baris # akan menjadi # 22 sehingga Anda tidak dapat mengetahui baris mana yang melempar pengecualian secara tepat (kecuali Anda hanya memiliki 1 atau beberapa baris kode di blok coba). Untuk mendapatkan garis yang diharapkan # 17 di pengecualian Anda, Anda harus membuang pengecualian baru dengan jejak tumpukan pengecualian asli.

Anda juga dapat menggunakan:

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

Dan setiap pengecualian yang dilemparkan akan menggelembung ke tingkat berikutnya yang menanganinya.

Saya pasti akan menggunakan:

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;
}

Itu akan menghemat tumpukan Anda.

FYI Saya baru saja menguji ini dan jejak stack dilaporkan oleh 'throw;' bukan jejak stack yang sepenuhnya benar. Contoh:

    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.
    }

Jejak tumpukan menunjuk ke asal pengecualian dengan benar (nomor baris yang dilaporkan) tetapi nomor baris yang dilaporkan untuk foo () adalah garis lemparan; pernyataan, maka Anda tidak bisa mengatakan mana dari panggilan ke bilah () yang menyebabkan pengecualian.