Tại sao các khối bắt trống là một ý tưởng tồi? [đóng cửa]

Tôi vừa thấy một câu hỏi về thử bắt , mà mọi người (bao gồm cả Jon Skeet) nói rằng các khối bắt trống là một ý tưởng thực sự tồi? Tại sao là cái này? Không có tình huống mà một sản phẩm khai thác trống không phải là một quyết định thiết kế sai?

Ý tôi là, chẳng hạn, đôi khi bạn muốn nhận thêm một số thông tin từ đâu đó (dịch vụ web, cơ sở dữ liệu) và bạn thực sự không quan tâm liệu bạn có nhận được thông tin này hay không. Vì vậy, bạn cố gắng để có được nó, và nếu có bất cứ điều gì xảy ra, điều đó ổn, tôi sẽ chỉ thêm một "bắt (Ngoại lệ bị bỏ qua) {}" và đó là tất cả

Thông thường, việc thử bắt trống là một ý tưởng tồi vì bạn đang âm thầm nuốt một điều kiện lỗi và sau đó tiếp tục thực hiện. Đôi khi, đây có thể là điều đúng đắn, nhưng thường đó là dấu hiệu cho thấy nhà phát triển đã thấy một ngoại lệ, không biết phải làm gì về vấn đề đó và vì vậy đã sử dụng một biện pháp bắt trống để làm im lặng vấn đề.

Đó là chương trình tương đương với việc dán băng keo đen lên đèn cảnh báo động cơ.

Tôi tin rằng cách bạn xử lý các trường hợp ngoại lệ phụ thuộc vào lớp phần mềm bạn đang làm việc: Ngoại lệ trong Rainforest .

Nói chung, chúng là một ý tưởng tồi bởi vì đó là một điều kiện thực sự hiếm gặp khi một thất bại (điều kiện đặc biệt, tổng quát hơn) được đáp ứng đúng với KHÔNG có phản ứng gì. Trên hết, catchcác khối trống là một công cụ phổ biến được sử dụng bởi những người sử dụng công cụ ngoại lệ để kiểm tra lỗi rằng họ nên thực hiện một cách ưu tiên.

Phải nói rằng điều đó luôn tệ là không đúng sự thật ... điều đó đúng với rất ít. Có thể có trường hợp bạn không quan tâm rằng có lỗi hoặc sự hiện diện của lỗi bằng cách nào đó cho thấy rằng bạn không thể làm gì về lỗi này (ví dụ: khi viết lỗi trước đó vào tệp nhật ký văn bản và bạn nhận được một IOException, có nghĩa là bạn không thể viết ra lỗi mới nào).

Tôi sẽ không nói quá nhiều rằng người sử dụng các khối bắt trống là một lập trình viên tồi và không biết anh ta đang làm gì ...

Tôi sử dụng khối bắt trống nếu cần thiết. Đôi khi lập trình viên của thư viện tôi đang tiêu thụ không biết anh ta đang làm gì và ném ngoại lệ ngay cả trong những tình huống khi không ai cần nó.

Ví dụ: hãy xem xét một số thư viện máy chủ http, tôi không quan tâm nếu máy chủ ném ngoại lệ vì máy khách bị ngắt kết nối và index.htmlkhông thể gửi được.

Có những trường hợp hiếm hoi mà nó có thể được biện minh. Trong Python bạn thường thấy kiểu xây dựng này:

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

Vì vậy, nó có thể ổn (tùy thuộc vào ứng dụng của bạn) để làm:

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

Trong một dự án .NET gần đây, tôi đã phải viết mã để liệt kê các DLL plugin để tìm các lớp thực hiện một giao diện nhất định. Mã bit có liên quan (trong VB.NET, xin lỗi) là:

    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

Mặc dù trong trường hợp này, tôi thừa nhận rằng việc ghi lại sự thất bại ở đâu đó có lẽ sẽ là một sự cải thiện.

Các khối bắt trống thường được đưa vào vì bộ mã hóa không thực sự biết họ đang làm gì. Tại tổ chức của tôi, một khối bắt trống phải bao gồm một nhận xét về lý do tại sao không làm gì với ngoại lệ là một ý tưởng tốt.

Trên một lưu ý liên quan, hầu hết mọi người không biết rằng một khối thử {} có thể được theo dõi bằng một lệnh bắt {} hoặc cuối cùng {}, chỉ cần một khối.

Các ngoại lệ chỉ nên được ném nếu thực sự có ngoại lệ - một cái gì đó xảy ra vượt quá tiêu chuẩn. Một khối bắt trống về cơ bản nói rằng "một cái gì đó xấu đang xảy ra, nhưng tôi không quan tâm". Đây là một ý tưởng tồi.

Nếu bạn không muốn xử lý ngoại lệ, hãy để nó lan truyền lên trên cho đến khi nó đạt đến một số mã có thể xử lý nó. Nếu không có gì có thể xử lý ngoại lệ, nó sẽ đưa ứng dụng xuống.

Tôi nghĩ rằng nó ổn nếu bạn bắt loại ngoại lệ cụ thể mà bạn biết rằng nó sẽ chỉ được nêu ra vì một lý do cụ thể và bạn mong đợi ngoại lệ đó và thực sự không cần phải làm gì về nó.

Nhưng ngay cả trong trường hợp đó, một thông báo gỡ lỗi có thể theo thứ tự.

Per Josh Bloch - Mục 65: Đừng bỏ qua Ngoại lệ của Java hiệu quả :

1. Một khối bắt trống đánh bại mục đích của ngoại lệ
2. Ít nhất, khối bắt phải chứa một bình luận giải thích lý do tại sao nó phù hợp để bỏ qua ngoại lệ.

Một khối bắt trống về cơ bản là nói rằng "Tôi không muốn biết lỗi nào được ném, tôi sẽ bỏ qua chúng."

Nó tương tự như VB6 On Error Resume Next, ngoại trừ mọi thứ trong khối thử sau khi ném ngoại lệ sẽ bị bỏ qua.

Mà không giúp được gì khi cái gì đó sau đó phá vỡ.

Điều này đi đôi với "Không sử dụng ngoại lệ để kiểm soát luồng chương trình." Và "Chỉ sử dụng ngoại lệ cho các trường hợp đặc biệt." Nếu những điều này được thực hiện, thì ngoại lệ chỉ nên xảy ra khi có vấn đề. Và nếu có vấn đề, bạn không muốn thất bại trong âm thầm. Trong các trường hợp dị thường hiếm khi không cần thiết phải xử lý sự cố, ít nhất bạn nên ghi lại ngoại lệ, chỉ trong trường hợp dị thường không còn là bất thường nữa. Điều duy nhất tồi tệ hơn thất bại là thất bại âm thầm.

Tôi nghĩ rằng một khối bắt hoàn toàn trống là một ý tưởng tồi bởi vì không có cách nào để suy luận rằng bỏ qua ngoại lệ là hành vi dự định của mã. Không nhất thiết là xấu khi nuốt một ngoại lệ và trả về false hoặc null hoặc một số giá trị khác trong một số trường hợp. Khung .net có nhiều phương thức "thử" hoạt động theo cách này. Theo nguyên tắc thông thường nếu bạn nuốt một ngoại lệ, hãy thêm nhận xét và tuyên bố nhật ký nếu ứng dụng hỗ trợ đăng nhập.

Bởi vì nếu một ngoại lệ được ném bạn sẽ không bao giờ nhìn thấy nó - không âm thầm là lựa chọn tồi tệ nhất có thể - bạn sẽ nhận được hành vi sai lầm và không có ý tưởng để nhìn nơi nó đang xảy ra. Ít nhất là đặt một thông điệp tường trình ở đó! Ngay cả khi đó là điều 'không bao giờ có thể xảy ra'!

Các khối bắt trống là một dấu hiệu của một lập trình viên không biết phải làm gì với một ngoại lệ. Họ đang ngăn chặn ngoại lệ có thể nổi lên và được xử lý chính xác bởi một khối thử khác. Luôn luôn cố gắng và làm một cái gì đó với ngoại lệ bạn đang nắm bắt.

Tôi thấy khó chịu nhất với các câu lệnh bắt trống là khi một số lập trình viên khác đã làm điều đó. Ý tôi là khi bạn cần gỡ lỗi mã từ người khác, bất kỳ câu lệnh bắt trống nào làm cho việc thực hiện như vậy trở nên khó khăn hơn. Các câu lệnh bắt IMHO phải luôn hiển thị một số loại thông báo lỗi - ngay cả khi lỗi không được xử lý, ít nhất nó cũng phải phát hiện ra (chỉ bật trong chế độ gỡ lỗi)

Có lẽ điều đó không bao giờ đúng vì bạn đang âm thầm vượt qua mọi ngoại lệ có thể. Nếu có một ngoại lệ cụ thể mà bạn mong đợi, thì bạn nên kiểm tra nó, suy nghĩ lại nếu đó không phải là ngoại lệ của bạ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;
}

Nói chung, bạn chỉ nên nắm bắt các ngoại lệ mà bạn thực sự có thể xử lý. Điều đó có nghĩa là càng cụ thể càng tốt khi bắt ngoại lệ. Nắm bắt tất cả các ngoại lệ hiếm khi là một ý tưởng tốt và bỏ qua tất cả các ngoại lệ gần như luôn luôn là một ý tưởng rất xấu.

Tôi chỉ có thể nghĩ về một vài trường hợp trong đó một khối bắt trống có mục đích nào đó có ý nghĩa. Nếu bất kỳ ngoại lệ cụ thể nào, bạn đang bắt được "xử lý" bằng cách chỉ đánh lừa hành động thì sẽ không cần phải làm gì trong khối bắt. Tuy nhiên, vẫn sẽ là một ý tưởng tốt để ghi lại sự thật rằng ngoại lệ xảy ra.

Một ví dụ khác: CLR 2.0 đã thay đổi cách xử lý các ngoại lệ chưa xử lý trên luồng hoàn thiện. Trước 2.0, quy trình được phép tồn tại trong kịch bản này. Trong CLR hiện tại, quá trình được kết thúc trong trường hợp ngoại lệ chưa được xử lý trên luồng hoàn thiện.

Hãy nhớ rằng bạn chỉ nên thực hiện một bộ hoàn thiện nếu bạn thực sự cần một cái và thậm chí sau đó bạn nên làm một chút có thể trong bộ hoàn thiện. Nhưng nếu bất cứ công việc nào mà trình hoàn thiện của bạn phải làm có thể tạo ra một ngoại lệ, bạn cần phải chọn giữa hai tệ nạn nhỏ hơn. Bạn có muốn tắt ứng dụng do ngoại lệ chưa xử lý? Hay bạn muốn tiến hành trong một trạng thái ít nhiều không xác định? Ít nhất trong lý thuyết, cái sau có thể là ít hơn của hai tệ nạn trong một số trường hợp. Trong những trường hợp đó, khối bắt trống sẽ ngăn quá trình bị chấm dứt.

Ý tôi là, chẳng hạn, đôi khi bạn muốn nhận thêm một số thông tin từ đâu đó (dịch vụ web, cơ sở dữ liệu) và bạn thực sự không quan tâm liệu bạn có nhận được thông tin này hay không. Vì vậy, bạn cố gắng để có được nó, và nếu có bất cứ điều gì xảy ra, điều đó ổn, tôi sẽ chỉ thêm một "bắt (Ngoại lệ bị bỏ qua) {}" và đó là tất cả

Vì vậy, đi theo ví dụ của bạn, đó là một ý tưởng tồi trong trường hợp đó bởi vì bạn đang nắm bắt và bỏ qua tất cả các ngoại lệ. Nếu bạn chỉ bắt EInfoFromIrrelevantSourceNotAvailablevà bỏ qua nó, điều đó sẽ ổn, nhưng bạn thì không. Bạn cũng đang bỏ qua ENetworkIsDown, điều này có thể hoặc không quan trọng. Bạn đang phớt lờ ENetworkCardHasMeltedvàEFPUHasDecidedThatOnePlusOneIsSeventeen , điều gần như chắc chắn quan trọng.

Khối bắt trống không phải là vấn đề nếu nó được thiết lập để chỉ bắt (và bỏ qua) các ngoại lệ của một số loại nhất định mà bạn biết là không quan trọng. Các tình huống trong đó là một ý tưởng tốt để ngăn chặn và âm thầm bỏ qua tất cả các ngoại lệ, mà không dừng lại để kiểm tra chúng trước để xem liệu chúng có được mong đợi / bình thường / không liên quan hay không, là cực kỳ hiếm.

Có những tình huống bạn có thể sử dụng chúng, nhưng chúng sẽ không thường xuyên. Các tình huống mà tôi có thể sử dụng một bao gồm:

• khai thác ngoại lệ; tùy thuộc vào ngữ cảnh, bạn có thể muốn có một ngoại lệ hoặc tin nhắn chưa được xử lý được đăng thay thế.

• lặp lại các tình huống kỹ thuật, như kết xuất hoặc xử lý âm thanh hoặc gọi lại hộp danh sách, trong đó chính hành vi đó sẽ giải quyết vấn đề, đưa ra một ngoại lệ sẽ gây cản trở và ghi nhật ký ngoại lệ có thể sẽ dẫn đến 1000 tin nhắn "không thành công" .

• các chương trình không thể thất bại, mặc dù ít nhất họ vẫn nên đăng nhập một cái gì đó.

đối với hầu hết các ứng dụng winforms, tôi đã thấy rằng nó đủ để có một tuyên bố thử duy nhất cho mỗi đầu vào của người dùng. Tôi sử dụng các phương thức sau: (AlertBox chỉ là một trình bao bọc MessageBox.Show nhanh)

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

Sau đó, mọi trình xử lý sự kiện có thể làm một cái gì đó như:

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

hoặc là

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

Về mặt lý thuyết, bạn có thể có TryActionSilently, có thể tốt hơn để kết xuất các cuộc gọi để một ngoại lệ không tạo ra vô số tin nhắn.

Nếu bạn không biết phải làm gì trong khối bắt, bạn chỉ có thể đăng nhập ngoại lệ này, nhưng không để trống.

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

Bạn không bao giờ nên có một khối bắt trống. Nó giống như che giấu một sai lầm mà bạn biết. Ít nhất bạn nên viết ra một ngoại lệ đối với tệp nhật ký để xem lại sau nếu bạn bị ép thời gian.