Chính sách xử lý ngoại lệ trong thư viện

Question

Khi xây dựng thư viện .NET, chính sách xử lý ngoại lệ của bạn là gì? Cụ thể, chính sách của bạn về xử lý ngoại lệ bên trong các cuộc gọi thư viện là gì và phơi bày chúng với mã gọi?

Ví dụ,

• Bạn có đối xử với một chức năng thư viện như bất kỳ khác, do đó cho phép tất cả các trường hợp ngoại lệ nó không thể xử lý chảy ra khỏi nó như nó vốn có?
• Bạn có tạo ngoại lệ tùy chỉnh cho thư viện đó không?
• Bạn có bắt được tất cả ngoại lệ và thay vào đó hãy ném ngoại lệ của thư viện? Bạn có đặt ngoại lệ ban đầu là ngoại lệ nội bộ ngoại lệ của thư viện không?
• Việc phụ thuộc thư viện vào DB ảnh hưởng như thế nào đến chính sách xử lý ngoại lệ của bạn?

Bạn sẽ đề xuất nguyên tắc và quy tắc nào để xử lý ngoại lệ trong thư viện .NET?

Answer 1

Bạn có đối xử với một chức năng thư viện như bất kỳ khác, do đó cho phép tất cả các trường hợp ngoại lệ nó không thể xử lý chảy ra khỏi nó như hiện trạng không?

Vâng, đây chắc chắn là chiến lược mặc định.

Bạn có tạo ngoại lệ tùy chỉnh cho thư viện đó không?

Vâng, nếu người gọi hình dung có thể làm điều gì đó về tình hình và để làm như vậy họ cần để có thể phân biệt các ngoại lệ từ ngoại lệ khác. Nhưng điều đó khá hiếm.

Việc phụ thuộc thư viện vào DB ảnh hưởng như thế nào đến chính sách xử lý ngoại lệ của bạn?

Phụ thuộc cơ sở dữ liệu có thể đòi hỏi phải đặt cài đặt cho phép người gọi chỉ định cách thư viện xử lý một số ngoại lệ nhất định (ví dụ: MaximumDeadlockRetries).

Bạn có bắt tất cả các trường hợp ngoại lệ và ném ngoại lệ của thư viện thay thế không? Bạn có đặt ngoại lệ ban đầu là ngoại lệ của thư viện bên trong ngoại lệ không?

Không, không phải tất cả ngoại lệ. Đối với các trường hợp ngoại lệ cụ thể, điều đó có thể từ xa, mặc dù trường hợp duy nhất tôi có thể nghĩ đến nơi tôi có thể muốn làm điều này là khi thư viện của tôi đã cố xử lý ngoại lệ (như trong kịch bản cơ sở dữ liệu ở trên) và thất bại.

Answer 2

• Tôi để tất cả bong bóng ngoại lệ mà tôi nghĩ người dùng có thể xử lý. Điều này về cơ bản là những thứ tôi nghĩ rằng anh ta nên mong đợi để xem (IO vv)
• Tôi quấn tất cả các eceptions mà tôi muốn trở lại một cách trừu tượng hơn. Trong một O/R mapper tôi đã có một "DataAccessException" có bất kỳ SQL Exception trong nội bộ - vì vậy người dùng không phải đối phó với nội tại của họ. Ý tưởng ở đây là bất kỳ ứng dụng có thể muốn biết một ngoại lệ cấp SQL đã xảy ra, nhưng thậm chí không thể cố gắng sửa chữa nó anyway (nhờ cơ sở dữ liệu là một trong nhiều loại vv) - vì vậy một wrapper là tốt.
• Tôi không bao giờ sử dụng chung nắm bắt tất cả các công cụ bên ngoài gỡ lỗi.
• Tôi luôn có trình xử lý cấp cao nhất (cấp ứng dụng - sự kiện ngoại lệ không được xử lý) để cố gắng hiển thị cho người dùng một ngoại lệ không mong muốn đã xảy ra và gửi nó để hỗ trợ.

Ngoại lệ tùy chỉnh - khi chúng có ý nghĩa. Đây không phải là trường hợp thường xuyên nhờ một số ngoại lệ chung trong khuôn khổ.

Answer 3

Một thư viện kết thúc tốt đẹp một số lớp khác nhau có thể ném các ngoại lệ khác nhau nên IMHO không cho phép ngoại lệ từ bên trong để lọc ra như các loại ban đầu của chúng. Thay vào đó, chúng phải được bao bọc trong một ngoại lệ cụ thể của thư viện mà rõ ràng nhất có thể liên quan đến loại ngoại lệ ban đầu. Ví dụ, MagicDatabaseLibrary có thể định nghĩa MagicDatabaseException, do đó có một vài ngoại lệ có nguồn gốc MagicDatabaseTimeoutException, MagicDatabaseAuthenticationException, vv. Nếu một cơ sở dữ liệu SQL Server ném ra một SQL Server Timeout Exception (bất kể nó được gọi là gì), cần được bao bọc trong một MagicDatabaseTimeoutException . Tương tự như vậy đối với bất kỳ trường hợp ngoại lệ bán kỳ vọng nào khác có thể xảy ra.

Nếu điều này không được thực hiện, mã gọi thư viện sẽ không có lựa chọn thực tế nhưng sử dụng "xử lý ngoại lệ Pokemon" nếu có bất kỳ hy vọng nào về các vấn đề cơ sở dữ liệu tiềm ẩn. Ví dụ, nếu mã gọi là nghĩa vụ phải xử lý tình huống mà người dùng cung cấp thông tin đăng nhập để đăng nhập vào cơ sở dữ liệu và kết nối không thành công, nó cần có khả năng bắt ngoại lệ đó. Nếu mã gọi không biết loại ngoại lệ sẽ là gì, bạn không thể làm gì ngoại trừ bắt mọi ngoại lệ, hy vọng đó là kết quả của thông tin xác thực không đúng hoặc thứ gì đó và hiển thị thông báo cho người dùng nói rằng kết nối không thành công . Không gần như hữu ích như cung cấp một ngoại lệ được bao bọc.