2010-06-21 22 views
6

Trong .NET, khi bắt ngoại lệ, tôi có nên luôn luôn bắt được các ngoại lệ có nguồn gốc (vì vậy không phải ArgumentException nhưng các kiểu dẫn xuất)?Nắm bắt hầu hết các trường hợp ngoại lệ có nguồn gốc?

Ngoài ra:

Nếu tôi yêu cầu sử dụng các mã lỗi, điều này sẽ được các nhà xây dựng như vậy ?:

ném ngoại lệ mới ("4000", ex);

Hoặc loại ngoại lệ tùy chỉnh có thuộc tính errorcode? (Điều này có thể gây nhầm lẫn với các loại ngoại lệ như SqlException có mã lỗi ánh xạ tới lỗi SQL Server).

Cảm ơn

+0

Mã lỗi đến từ đâu? Các mã lỗi đó có phải là mã lỗi Win32 gốc không? –

Trả lời

6
  1. Ghi ngoại lệ rộng nhất mà bạn biết cách xử lý.

    Nói chung, điều này có nghĩa là bạn sẽ bắt được một ngoại lệ khá cụ thể. Và một số ngoại lệ, chẳng hạn như ArgumentException s, không nên bị phát hiện ở tất cả b/c, chúng cho biết lỗi logic thay vì lỗi thời gian chạy. Một nơi mà tôi đã tìm thấy bắt một ngoại lệ rộng hơn hữu ích là trong trường hợp của File I/O. An IOException có thể là một ngoại lệ cao cấp thực tế để bắt.

  2. Nếu bạn được yêu cầu sử dụng mã lỗi, bạn có thể sử dụng thuộc tính thư của một ngoại lệ để bọc nó, nhưng tôi sẽ không bao giờ sử dụng nó làm lý do để tránh ném một ngoại lệ được nhập thích hợp. Điều này là do có hai mối quan tâm riêng biệt tại đây:

    a. Mã lỗi là có để cung cấp một phần thông tin cụ thể có thể được tra cứu trong trường hợp lỗi trong trường. Nó không bao giờ nên được sử dụng để phân biệt giữa các loại ngoại lệ b/c theo lập trình ngôn ngữ có một cơ sở cụ thể được thiết kế cho rằng: các loại ngoại lệ.

    b. Trường hợp ngoại lệ được nhập thích hợp là ở đó để cung cấp cách thức có lập trình để phân biệt giữa các ngoại lệ. Ngôn ngữ được thiết kế cho nó, sử dụng nó. Không bao giờ ném một đồng bằng Exception.

    Tôi có thể sẽ ném mã lỗi vào số Exception.Data collection. Điều này tránh ghi đè thư trong Exception.Message mà nếu không sẽ rất hữu ích cho mục đích chẩn đoán.

+0

Tôi không chắc chắn có nhiều cơ sở nói chung liên quan đến ArgumentException là nhiều hay ít "nghiêm trọng" hơn nhiều loại khác. Điều mà người ta thực sự cần biết khi bắt một ngoại lệ là trạng thái của hệ thống (và liệu thói quen ném ngoại lệ có ảnh hưởng đến nó hay không).Nếu cố gắng, ví dụ: phân tích cú pháp một tệp, tôi không chắc có nhiều giá trị trong việc xác nhận tất cả các trường trước khi gọi các thường trình sẽ ném ArgumentException nếu đối số của chúng không hợp lệ, trừ khi mã của riêng tôi có thể làm điều gì đó hữu ích hơn ném một ngoại lệ cho đầu vào không hợp lệ. Vì vậy, tôi hầu như không thấy rằng nó ngụ ý "lỗi logic". – supercat

2

Điều này phụ thuộc vào việc bạn muốn bắt ngoại lệ chính xác hoặc một nhóm loại ngoại lệ khác.

Đôi khi bạn chỉ muốn thêm xử lý cho 1 ngoại lệ chính xác. Những lần khác, việc xử lý ngoại lệ của bạn sẽ giống nhau đối với bất kỳ loại ngoại lệ nào, do đó bạn chỉ có thể bắt hoặc chỉ bắt được Exception để xem ngoại lệ là gì.

Ví dụ: bạn có thể chỉ muốn bắt 1 ngoại lệ chính xác và không xử lý ngoại lệ khác. Bạn sẽ làm điều đó khi bạn biết rõ hơn về ngăn xếp cuộc gọi, bạn bắt được phần còn lại của các ngoại lệ nhưng bạn chỉ muốn bỏ qua chính xác thứ bạn đang bắt chính xác.

Các vấn đề liên quan