Tại sao bắt và suy nghĩ lại một ngoại lệ trong C #?

Tôi đang xem bài viết C # - Đối tượng truyền dữ liệu về các DTO tuần tự hóa.

Bài viết bao gồm đoạn mã này:

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    }
    catch(Exception ex) {
        throw ex;
    }
}

Phần còn lại của bài viết có vẻ lành mạnh và hợp lý (với một người mới), nhưng việc ném thử đó ném WtfException ... Điều này có hoàn toàn tương đương với việc không xử lý ngoại lệ không?

Ergo:

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

Hay tôi thiếu một cái gì đó cơ bản về xử lý lỗi trong C #? Nó khá giống với Java (trừ các trường hợp ngoại lệ được kiểm tra), phải không? ... Đó là, cả hai đều tinh chế C ++.

Câu hỏi về Stack Overflow Sự khác biệt giữa việc bắt lại tham số ít hơn và không làm gì cả? dường như ủng hộ sự tranh giành của tôi rằng try-Catch-throw là-không-op.

BIÊN TẬP:

Chỉ cần tóm tắt cho bất cứ ai tìm thấy chủ đề này trong tương lai ...

ĐỪNG

try {
    // Do stuff that might throw an exception
}
catch (Exception e) {
    throw e; // This destroys the strack trace information!
}

Thông tin theo dõi ngăn xếp có thể rất quan trọng để xác định nguyên nhân gốc rễ của vấn đề!

LÀM

try {
    // Do stuff that might throw an exception
}
catch (SqlException e) {
    // Log it
    if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
        // Do special cleanup, like maybe closing the "dirty" database connection.
        throw; // This preserves the stack trace
    }
}
catch (IOException e) {
    // Log it
    throw;
}
catch (Exception e) {
    // Log it
    throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
    // Normal clean goes here (like closing open files).
}

Nắm bắt các ngoại lệ cụ thể hơn trước các ngoại lệ ít cụ thể hơn (giống như Java).

Người giới thiệu:

• MSDN - Xử lý ngoại lệ
• MSDN - thử bắt (Tham khảo C #)

Đầu tiên; cách mà đoạn mã trong bài viết thực hiện nó là xấu xa. throw exsẽ thiết lập lại ngăn xếp cuộc gọi ngoại lệ đến điểm có câu lệnh ném này; mất thông tin về nơi thực sự ngoại lệ được tạo ra.

Thứ hai, nếu bạn chỉ bắt và ném lại như vậy, tôi thấy không có giá trị gia tăng nào, ví dụ mã ở trên sẽ tốt như vậy (hoặc, được cung cấp throw exbit, thậm chí tốt hơn) mà không cần thử bắt.

Tuy nhiên, có những trường hợp bạn có thể muốn bắt và suy nghĩ lại một ngoại lệ. Ghi nhật ký có thể là một trong số đó:

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

Đừng làm điều này,

try 
{
...
}
catch(Exception ex)
{
   throw ex;
}

Bạn sẽ mất thông tin theo dõi ngăn xếp ...

Hoặc là làm

try { ... }
catch { throw; }

HOẶC LÀ

try { ... }
catch (Exception ex)
{
    throw new Exception("My Custom Error Message", ex);
}

Một trong những lý do bạn có thể muốn nghĩ lại là nếu bạn xử lý các ngoại lệ khác nhau, ví dụ:

try
{
   ...
}
catch(SQLException sex)
{
   //Do Custom Logging 
   //Don't throw exception - swallow it here
}
catch(OtherException oex)
{
   //Do something else
   throw new WrappedException("Other Exception occured");
}
catch
{
   System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
   throw; //Chuck everything else back up the stack
}

C # (trước C # 6) không hỗ trợ "ngoại lệ được lọc" của CIL, mà VB thực hiện, do đó, trong C # 1-5, một lý do để ném lại một ngoại lệ là bạn không có đủ thông tin tại thời điểm bắt () để xác định xem bạn có thực sự muốn bắt ngoại lệ hay không.

Ví dụ, trong VB bạn có thể làm

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

... sẽ không xử lý MyExceptions với các giá trị ErrorCode khác nhau. Trong C # trước v6, bạn sẽ phải bắt và ném lại MyException nếu ErrorCode không phải là 123:

try 
{
   ...
}
catch(MyException ex)
{
    if (ex.ErrorCode != 123) throw;
    ...
}

Vì C # 6.0, bạn có thể lọc giống như với VB:

try 
{
  // Do stuff
} 
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
  // Handle, other exceptions will be left alone and bubble up
}

Lý do chính của tôi để có mã như:

try
{
    //Some code
}
catch (Exception e)
{
    throw;
}

là vì vậy tôi có thể có một điểm dừng trong bẫy, có một đối tượng ngoại lệ được khởi tạo. Tôi làm điều này rất nhiều trong khi phát triển / gỡ lỗi. Tất nhiên, trình biên dịch cung cấp cho tôi một cảnh báo về tất cả các e chưa sử dụng và lý tưởng là chúng nên được gỡ bỏ trước khi xây dựng bản phát hành.

Họ là tốt đẹp trong khi gỡ lỗi mặc dù.

Một lý do hợp lệ để lấy lại ngoại lệ có thể là bạn muốn thêm thông tin vào ngoại lệ hoặc có thể bao bọc ngoại lệ ban đầu trong một trong những cách tạo của riêng bạn:

public static string SerializeDTO(DTO dto) {
  try {
      XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
      StringWriter sWriter = new StringWriter();
      xmlSer.Serialize(sWriter, dto);
      return sWriter.ToString();
  }
  catch(Exception ex) {
    string message = 
      String.Format("Something went wrong serializing DTO {0}", DTO);
    throw new MyLibraryException(message, ex);
  }
}

Điều này có chính xác tương đương với việc không xử lý ngoại lệ nào không?

Không chính xác, nó không giống nhau. Nó đặt lại stacktrace của ngoại lệ. Mặc dù tôi đồng ý rằng đây có thể là một sai lầm, và do đó là một ví dụ về mã xấu.

Bạn không muốn ném ex - vì điều này sẽ làm mất ngăn xếp cuộc gọi. Xem Xử lý ngoại lệ (MSDN).

Và vâng, thử ... bắt không làm gì hữu ích (ngoài việc mất ngăn xếp cuộc gọi - vì vậy nó thực sự tồi tệ hơn - trừ khi vì một lý do nào đó bạn không muốn tiết lộ thông tin này).

Một điểm mà mọi người chưa đề cập là trong khi các ngôn ngữ .NET không thực sự phân biệt chính xác, câu hỏi liệu người ta có nên hành động khi có ngoại lệ xảy ra hay không và liệu người ta có giải quyết được không, thực sự là những câu hỏi riêng biệt. Có nhiều trường hợp người ta phải hành động dựa trên ngoại lệ, người ta không có hy vọng giải quyết, và có một số trường hợp tất cả những gì cần thiết để "giải quyết" một ngoại lệ là giải phóng ngăn xếp đến một điểm nhất định - không cần phải thực hiện thêm hành động nào .

Bởi vì sự khôn ngoan thông thường mà người ta chỉ nên "bắt" những thứ mà người ta có thể "xử lý", rất nhiều mã sẽ hành động khi có ngoại lệ xảy ra, không. Ví dụ, rất nhiều mã sẽ thu được khóa, đưa đối tượng được bảo vệ "tạm thời" vào trạng thái vi phạm bất biến của nó, sau đó đưa đối tượng vào trạng thái hợp pháp và sau đó nhả khóa lại trước khi bất kỳ ai khác có thể nhìn thấy đối tượng. Nếu một ngoại lệ xảy ra trong khi đối tượng ở trạng thái không hợp lệ nguy hiểm, thực tế phổ biến là giải phóng khóa với đối tượng vẫn ở trạng thái đó. Một mô hình tốt hơn nhiều sẽ có một ngoại lệ xảy ra trong khi đối tượng ở trong tình trạng "nguy hiểm" rõ ràng vô hiệu hóa khóa, vì vậy mọi nỗ lực trong tương lai để có được nó sẽ ngay lập tức thất bại.

Trong hầu hết các ngôn ngữ .NET, cách duy nhất để mã thực hiện hành động dựa trên một ngoại lệ là catchnó (mặc dù nó biết rằng nó sẽ không giải quyết ngoại lệ), thực hiện hành động được đề cập và sau đó lại throw). Một cách tiếp cận khả thi khác nếu mã không quan tâm đến ngoại lệ nào được ném là sử dụng okcờ có try/finallykhối; đặt okcờ thành falsetrước khối và truetrước khi khối thoát ra và trước bất kỳ khối nào returntrong khối. Sau đó, bên trong finally, giả sử rằng nếu okkhông được đặt, một ngoại lệ phải xảy ra. Cách tiếp cận như vậy tốt hơn về mặt ngữ nghĩa so với a catch/ throw, nhưng xấu và ít được bảo trì hơn mức cần thiết.

Điều này có thể hữu ích khi chức năng lập trình của bạn cho một thư viện hoặc dll.

Cấu trúc suy nghĩ lại này có thể được sử dụng để thiết lập lại mục đích ngăn xếp cuộc gọi để thay vì nhìn thấy ngoại lệ được ném từ một hàm riêng lẻ bên trong hàm, bạn sẽ nhận được ngoại lệ từ chính hàm đó.

Tôi nghĩ rằng nó chỉ được sử dụng để các ngoại lệ được ném sạch hơn và không đi vào "gốc rễ" của thư viện.

Một lý do có thể để bắt-ném là vô hiệu hóa bất kỳ bộ lọc ngoại lệ nào sâu hơn ngăn xếp khỏi việc lọc xuống ( liên kết cũ ngẫu nhiên ). Nhưng tất nhiên, nếu đó là ý định, sẽ có một bình luận ở đó nói như vậy.

Nó phụ thuộc vào những gì bạn đang làm trong khối bắt và liệu bạn có muốn chuyển lỗi sang mã gọi hay không.

Bạn có thể nói Catch io.FileNotFoundExeption exvà sau đó sử dụng một đường dẫn tệp thay thế hoặc một số như vậy, nhưng vẫn gây ra lỗi.

Cũng làm Throwthay vì Throw Excho phép bạn giữ dấu vết ngăn xếp đầy đủ. Ném ex khởi động lại dấu vết ngăn xếp từ câu lệnh ném (tôi hy vọng điều đó có ý nghĩa).

Mặc dù nhiều câu trả lời khác cung cấp các ví dụ hay về lý do tại sao bạn có thể muốn bắt lại một ngoại lệ, nhưng dường như không ai đề cập đến một kịch bản 'cuối cùng'.

Một ví dụ về điều này là nơi bạn có một phương thức trong đó bạn đặt con trỏ (ví dụ: con trỏ chờ), phương thức này có một số điểm thoát (ví dụ: if () return;) và bạn muốn đảm bảo con trỏ được đặt lại tại kết thúc phương pháp.

Để làm điều này, bạn có thể bọc tất cả các mã trong một thử / bắt / cuối cùng. Cuối cùng, đặt con trỏ trở lại con trỏ bên phải. Vì vậy, bạn không chôn bất kỳ trường hợp ngoại lệ hợp lệ nào, hãy suy nghĩ lại về việc nắm bắt.

try
{
    Cursor.Current = Cursors.WaitCursor;
    // Test something
    if (testResult) return;
    // Do something else
}
catch
{
    throw;
}
finally
{
     Cursor.Current = Cursors.Default;
}

Trong ví dụ trong đoạn mã bạn đã đăng, trên thực tế, không có điểm nào bắt được ngoại lệ vì không có gì được thực hiện khi bắt nó, nó thực sự gây hại nhiều hơn là tốt khi ngăn xếp cuộc gọi bị mất .

Tuy nhiên, bạn sẽ bắt một ngoại lệ để thực hiện một số logic (ví dụ: đóng kết nối sql của khóa tệp hoặc chỉ ghi nhật ký) trong trường hợp ngoại lệ, hãy ném nó trở lại mã gọi để xử lý. Điều này sẽ phổ biến hơn trong một lớp nghiệp vụ so với mã giao diện người dùng vì bạn có thể muốn người viết mã triển khai lớp doanh nghiệp của bạn để xử lý ngoại lệ.

Để lặp lại mặc dù KHÔNG có điểm nào trong việc bắt ngoại lệ trong ví dụ bạn đã đăng. ĐỪNG làm như vậy!

Xin lỗi, nhưng nhiều ví dụ như "thiết kế cải tiến" vẫn có mùi khủng khiếp hoặc có thể cực kỳ sai lệch. Đã thử {} bắt {log; ném} là hoàn toàn vô nghĩa. Ghi nhật ký ngoại lệ nên được thực hiện ở vị trí trung tâm bên trong ứng dụng. ngoại lệ bong bóng stacktrace nào, tại sao không đăng nhập chúng ở đâu đó và gần với biên giới của hệ thống?

Cần thận trọng khi bạn tuần tự hóa ngữ cảnh của mình (ví dụ DTO trong một ví dụ cụ thể) chỉ vào thông điệp tường trình. Nó có thể dễ dàng chứa thông tin nhạy cảm mà người ta có thể không muốn đến tay tất cả những người có thể truy cập các tệp nhật ký. Và nếu bạn không thêm bất kỳ thông tin mới nào vào ngoại lệ, tôi thực sự không thấy điểm của gói ngoại lệ. Java cũ tốt có một số điểm cho điều đó, nó đòi hỏi người gọi phải biết loại ngoại lệ nào mà người ta mong đợi sau đó gọi mã. Vì bạn không có cái này trong .NET, nên việc gói không làm gì tốt với ít nhất 80% các trường hợp tôi đã thấy.

Ngoài những gì người khác đã nói, hãy xem câu trả lời của tôi cho một câu hỏi liên quan cho thấy rằng việc nắm bắt và suy nghĩ lại không phải là không có (nó có trong VB, nhưng một số mã có thể được gọi là C # từ VB).

Hầu hết các câu trả lời nói về kịch bản bắt-log-rethrow.

Thay vì viết nó vào mã của bạn, hãy cân nhắc sử dụng AOP, đặc biệt là Postsharp.Diagnellect.Toolkit với OnExceptionOptions Bao gồmParameterValue và Bao gồmArArument

Lấy lại các ngoại lệ thông qua throwrất hữu ích khi bạn không có một mã cụ thể để xử lý các ngoại lệ hiện tại hoặc trong trường hợp khi bạn có logic để xử lý các trường hợp lỗi cụ thể nhưng muốn bỏ qua tất cả các trường hợp khác.

Thí dụ:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException)
{
    if (numberText.ToLowerInvariant() == "nothing")
    {
        Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
    }
    else
    {
        throw;
    }
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

Tuy nhiên, cũng có một cách khác để làm điều này, sử dụng mệnh đề có điều kiện trong các khối bắt:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException) when (numberText.ToLowerInvariant() == "nothing")
{
    Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

Cơ chế này hiệu quả hơn so với ném lại một ngoại lệ vì thời gian chạy .NET không phải xây dựng lại đối tượng ngoại lệ trước khi ném lại.