Đối số chống lại lỗi

Tôi đã tìm thấy một đoạn mã như thế này trong một trong các dự án của chúng tôi:

    SomeClass QueryServer(string args)
    {
        try
        {
            return SomeClass.Parse(_server.Query(args));
        }
        catch (Exception)
        {
            return null;
        }
    }

Theo tôi hiểu, việc loại bỏ các lỗi như thế này là một thực tiễn tồi, vì nó phá hủy thông tin hữu ích từ ngoại lệ của máy chủ ban đầu và làm cho mã tiếp tục khi thực sự nên chấm dứt.

Khi nào thì thích hợp để triệt tiêu hoàn toàn mọi lỗi như thế này?

Hãy tưởng tượng mã với hàng ngàn tệp bằng cách sử dụng một loạt các thư viện. Hãy tưởng tượng tất cả chúng đều được mã hóa như thế này.

Ví dụ, hãy tưởng tượng một bản cập nhật của máy chủ của bạn khiến một tệp cấu hình biến mất; và bây giờ tất cả những gì bạn có là một dấu vết ngăn xếp là một ngoại lệ con trỏ null khi bạn thử sử dụng lớp đó: bạn sẽ giải quyết nó như thế nào? Có thể mất hàng giờ, trong đó ít nhất chỉ cần ghi lại dấu vết ngăn xếp thô của tệp không tìm thấy [đường dẫn tệp] có thể cho phép bạn giải quyết trong giây lát.

Hoặc thậm chí tệ hơn: một lỗi trong một trong các thư viện bạn sử dụng sau khi cập nhật khiến mã của bạn bị sập sau này. Làm thế nào bạn có thể theo dõi điều này trở lại thư viện?

Ngay cả khi không xử lý lỗi mạnh mẽ chỉ cần làm

throw new IllegalStateException("THIS SHOULD NOT HAPPENING")

hoặc là

LOGGER.error("[method name]/[arguments] should not be there")

có thể giúp bạn tiết kiệm nhiều giờ

Nhưng có một số trường hợp bạn thực sự muốn bỏ qua ngoại lệ và trả về null như thế này (hoặc không làm gì cả). Đặc biệt là nếu bạn tích hợp với một số mã kế thừa được thiết kế xấu và ngoại lệ này được dự kiến ​​là một trường hợp bình thường.

Trong thực tế khi làm điều này, bạn chỉ nên tự hỏi nếu bạn thực sự đang bỏ qua ngoại lệ hoặc "xử lý đúng" cho nhu cầu của bạn. Nếu trả về null là "xử lý đúng" ngoại lệ của bạn trong trường hợp cụ thể đó, thì hãy làm điều đó. Và thêm một bình luận tại sao đây là điều thích hợp để làm.

Thực hành tốt nhất là những điều cần tuân thủ trong hầu hết các trường hợp, có thể 80%, có thể 99%, nhưng bạn sẽ luôn tìm thấy một trường hợp cạnh mà họ không áp dụng. Trong trường hợp đó, hãy để lại nhận xét tại sao bạn không theo dõi thông lệ cho những người khác (hoặc thậm chí chính bạn), người sẽ đọc mã của bạn vài tháng sau đó.

Có những trường hợp mẫu này hữu ích - nhưng chúng thường được sử dụng khi ngoại lệ được tạo không bao giờ nên có (nghĩa là khi ngoại lệ được sử dụng cho hành vi bình thường).

Ví dụ, hãy tưởng tượng bạn có một lớp mở tệp, lưu trữ nó trong đối tượng được trả về. Nếu tệp không tồn tại, bạn có thể coi đó không phải là trường hợp lỗi, bạn trả về null và để người dùng tạo tệp mới thay thế. Phương pháp mở tệp có thể đưa ra một ngoại lệ ở đây để cho biết không có tệp nào xuất hiện, do đó, việc âm thầm bắt nó có thể là một tình huống hợp lệ.

Tuy nhiên, không thường xuyên bạn muốn làm điều này và nếu mã bị vấy bẩn với một mẫu như vậy bạn muốn xử lý ngay bây giờ. Ít nhất tôi mong đợi một cái bẫy im lặng như vậy để viết một dòng nhật ký nói rằng đây là những gì đã xảy ra (bạn có dấu vết, phải) và một bình luận để giải thích hành vi này.

Đây là phụ thuộc 100% bối cảnh. Nếu người gọi của chức năng đó có yêu cầu hiển thị hoặc ghi nhật ký lỗi ở đâu đó, thì rõ ràng là vô nghĩa. Nếu người gọi bỏ qua tất cả các lỗi hoặc thông báo ngoại lệ, sẽ không có ý nghĩa gì khi trả lại ngoại lệ hoặc tin nhắn của nó. Khi yêu cầu là làm cho mã chỉ chấm dứt mà không hiển thị bất kỳ lý do nào, thì một cuộc gọi

   if(QueryServer(args)==null)
      TerminateProgram();

có lẽ sẽ là đủ Bạn phải xem xét nếu điều này sẽ làm cho người dùng khó tìm ra nguyên nhân gây ra lỗi - nếu đó là trường hợp, đây là hình thức xử lý lỗi sai. Tuy nhiên, nếu mã cuộc gọi trông như thế này

  result = QueryServer(args);
  if(result!=null)
      DoSomethingMeaningful(result);
  // else ??? Mask the error and let the user run into trouble later

sau đó bạn nên có một đối số với nhà phát triển trong quá trình xem xét mã. Nếu ai đó thực hiện một hình thức xử lý không lỗi như vậy chỉ vì anh ta quá lười biếng để tìm hiểu về các yêu cầu chính xác, thì mã này sẽ không được đưa vào sản xuất và tác giả của mã nên được dạy về hậu quả có thể xảy ra của sự lười biếng đó .

Trong những năm tôi đã dành lập trình và phát triển hệ thống, chỉ có hai tình huống tôi thấy mô hình được đề cập là hữu ích (trong cả hai trường hợp, áp lực cũng bao gồm ghi nhật ký ngoại lệ bị ném, tôi không coi việc bắt và nulltrả lại đơn giản là một cách thực hành tốt ).

Hai tình huống như sau:

1. Khi ngoại lệ không được coi là một trạng thái ngoại lệ

Đây là khi bạn thực hiện một thao tác trên một số dữ liệu, có thể ném, bạn biết nó có thể ném nhưng bạn vẫn muốn ứng dụng của mình tiếp tục chạy, vì bạn không cần dữ liệu đã xử lý. Nếu bạn nhận được chúng, thật tốt, nếu bạn không, nó cũng tốt.

Một số thuộc tính tùy chọn của một lớp có thể xuất hiện trong tâm trí.

2. Khi bạn đang cung cấp triển khai thư viện mới (tốt hơn, nhanh hơn?) Bằng giao diện đã được sử dụng trong ứng dụng

Hãy tưởng tượng bạn có một ứng dụng sử dụng một loại thư viện cũ, không ném ngoại lệ nhưng bị nulllỗi. Vì vậy, bạn đã tạo một bộ điều hợp cho thư viện này, sao chép khá nhiều API gốc của thư viện và đang sử dụng giao diện mới (vẫn không ném) này trong ứng dụng của bạn và tự xử lý nullkiểm tra.

Một phiên bản mới của thư viện xuất hiện, hoặc có lẽ là một thư viện hoàn toàn khác cung cấp cùng chức năng, thay vì trả về nulls, sẽ ném ngoại lệ và bạn muốn sử dụng nó.

Bạn không muốn rò rỉ các ngoại lệ cho ứng dụng chính của mình, vì vậy bạn thay thế và đăng nhập chúng trong bộ điều hợp bạn tạo để bọc phụ thuộc mới này.

Trường hợp đầu tiên không phải là một vấn đề, đó là hành vi mong muốn của mã. Tuy nhiên, trong tình huống thứ hai, nếu ở mọi nơi nullgiá trị trả về của bộ điều hợp thư viện thực sự có nghĩa là có lỗi, thì việc tái cấu trúc API để đưa ra một ngoại lệ và bắt nó thay vì kiểm tra nullcó thể là (và thông thường là mã) là một ý tưởng tốt.

Cá nhân tôi chỉ sử dụng siêu áp lực cho trường hợp đầu tiên. Tôi chỉ sử dụng nó cho trường hợp thứ hai, khi chúng tôi không có ngân sách để làm cho phần còn lại của ứng dụng hoạt động với các ngoại lệ thay vì nulls.

Mặc dù có vẻ hợp lý khi nói rằng các chương trình chỉ nên nắm bắt các ngoại lệ mà chúng biết cách xử lý và không thể biết cách xử lý các ngoại lệ mà lập trình viên không lường trước được, một tuyên bố như vậy bỏ qua thực tế là nhiều hoạt động có thể thất bại trong một gần như vô hạn các cách không có tác dụng phụ, và trong nhiều trường hợp, việc xử lý thích hợp cho phần lớn các lỗi như vậy sẽ giống hệt nhau; các chi tiết chính xác của sự thất bại sẽ không liên quan, và do đó, không quan trọng việc lập trình viên có lường trước được chúng hay không.

Ví dụ, nếu mục đích của chức năng là đọc tệp tài liệu vào một đối tượng phù hợp và tạo một cửa sổ tài liệu mới để hiển thị đối tượng đó hoặc báo cáo cho người dùng rằng tệp không thể đọc được, hãy thử tải một tệp Tệp tài liệu không hợp lệ không nên làm sập ứng dụng - thay vào đó, nó sẽ hiển thị một thông báo cho biết sự cố nhưng để phần còn lại của ứng dụng tiếp tục chạy bình thường trừ khi vì lý do nào đó, việc tải tài liệu đã làm hỏng trạng thái của một thứ khác trong hệ thống .

Về cơ bản, việc xử lý thích hợp một ngoại lệ thường sẽ phụ thuộc ít hơn vào loại ngoại lệ so với vị trí mà nó được ném; nếu một tài nguyên được bảo vệ bởi khóa đọc ghi và một ngoại lệ được ném vào một phương thức đã thu được khóa để đọc, thì hành vi thích hợp thường là giải phóng khóa vì phương thức đó không thể làm gì đối với tài nguyên . Nếu một ngoại lệ được ném trong khi khóa được lấy để ghi, khóa thường sẽ bị vô hiệu, vì tài nguyên được bảo vệ có thể ở trạng thái không hợp lệ; nếu nguyên thủy khóa không có trạng thái "vô hiệu", người ta nên thêm một cờ để theo dõi sự vô hiệu đó. Phát hành khóa mà không làm mất hiệu lực nó là xấu vì mã khác có thể thấy đối tượng được bảo vệ ở trạng thái không hợp lệ. Rời khỏi ổ khóa, tuy nhiên, không phải là ' Giải pháp thích hợp hoặc. Giải pháp phù hợp là vô hiệu hóa khóa để mọi nỗ lực mua lại trong tương lai hoặc đang chờ xử lý sẽ ngay lập tức thất bại.

Nếu nó chỉ ra rằng một tài nguyên không hợp lệ bị bỏ rơi trước khi có bất kỳ nỗ lực sử dụng nào, thì không có lý do gì để đưa ứng dụng xuống. Nếu tài nguyên không hợp lệ là rất quan trọng đối với hoạt động liên tục của ứng dụng, ứng dụng sẽ cần phải được đưa xuống nhưng việc vô hiệu hóa tài nguyên có thể sẽ khiến điều đó xảy ra. Mã nhận được ngoại lệ ban đầu thường sẽ không có cách nào để biết tình huống nào được áp dụng, nhưng nếu nó làm mất hiệu lực tài nguyên, nó có thể đảm bảo rằng hành động chính xác cuối cùng sẽ được thực hiện trong cả hai trường hợp.

Nuốt loại lỗi này không đặc biệt hữu ích với bất kỳ ai. Có, người gọi ban đầu có thể không quan tâm đến ngoại lệ nhưng người khác có thể .

Vậy thì họ làm gì? Họ sẽ thêm mã để xử lý ngoại lệ để xem hương vị của ngoại lệ nào họ sẽ quay lại. Tuyệt quá. Nhưng nếu trình xử lý ngoại lệ được để lại, người gọi ban đầu sẽ không còn trở lại null và một cái gì đó bị phá vỡ ở nơi khác.

Ngay cả khi bạn biết rằng một số mã ngược dòng có thể gây ra lỗi và do đó trả về null, điều đó sẽ khiến bạn không cố gắng ít nhất là cố gắng loại bỏ ngoại lệ trong mã gọi IMHO.

Tôi đã thấy các ví dụ trong đó các thư viện của bên thứ ba có các phương thức hữu ích, ngoại trừ việc họ đưa ra các ngoại lệ trong một số trường hợp phù hợp với tôi. Tôi có thể làm gì?

• Thực hiện chính xác những gì tôi cần bản thân mình. Có thể khó khăn về thời hạn.
• Sửa đổi mã của bên thứ ba. Nhưng sau đó tôi phải tìm kiếm xung đột hợp nhất với mỗi lần nâng cấp.
• Viết phương thức trình bao bọc để biến ngoại lệ thành một con trỏ null thông thường, sai boolean hoặc bất cứ điều gì.

Ví dụ: phương thức thư viện

public foo findFoo() {...} 

trả về foo đầu tiên, nhưng nếu không có nó sẽ ném ngoại lệ. Nhưng cái tôi cần là một phương thức để trả về foo đầu tiên hoặc null. Vì vậy, tôi viết cái này:

public foo myFindFoo() {
    try {
        return findFoo() 
    } 
    catch (NoFooException ex) {
        return null;
    }
}

Không gọn gàng. Nhưng đôi khi là giải pháp thực dụng.