2009-08-10 28 views
8

Trong Java, thỉnh thoảng tôi sẽ ném trực tiếp AssertionError, để khẳng định rằng một dòng cụ thể sẽ không đạt được. Một ví dụ về điều này sẽ là để khẳng định rằng trường hợp default trong một tuyên bố switch không thể đạt được (xem this JavaSpecialists page cho một ví dụ).. Net tương đương với Java AssertionError

Tôi muốn sử dụng cơ chế tương tự trong .Net. Có ngoại lệ tương đương mà tôi có thể sử dụng không? Hoặc là có một phương pháp khác có thể được sử dụng với cùng một hiệu ứng?

Chỉnh sửa - Để làm rõ, tôi đang tìm một cơ chế để gắn cờ thất bại trong thời gian chạy, trong mã được phát hành, để chỉ ra rằng đã có lỗi (có thể thảm khốc) của một số bất biến trong mã. Ví dụ liên kết tạo ra một số nguyên ngẫu nhiên từ 0 đến 2 (bao gồm) và xác nhận rằng số được tạo luôn là 0, 1 hoặc 2. Nếu xác nhận này không giữ, sẽ tốt hơn nếu ngừng thực thi hoàn toàn thay vì tiếp tục với một số không xác định trạng thái hỏng của hệ thống.

Trả lời

8

Tôi thường ném InvalidOperationException hoặc ArgumentOutOfRangeException tùy thuộc vào nơi giá trị đến từ đâu.

Ngoài ra, có Debug.Assert (mà sẽ chỉ thất bại khi bạn đã có những biểu tượng DEBUG tiền xử lý được xác định) hoặc trong .NET 4.0 bạn có thể sử dụng Contract.Fail, Contract.Assert hoặc Contract.Assume tùy thuộc vào tình hình. Rõ ràng ném một ngoại lệ có lợi ích mà trình biên dịch biết rằng tuyên bố tiếp theo là không thể truy cập mặc dù.

Tôi không phải là người hâm mộ lớn của Debug.Assert - thường không thích hợp cho bản phát hành (vì nó ném hộp xác nhận thay vì chỉ thất bại) và theo mặc định, nó sẽ không được kích hoạt khi phát hành. Tôi thích các trường hợp ngoại lệ luôn bị ném vì chúng ngăn mã của bạn tiếp tục bất kể sau khi có cơ hội phát hiện "nội dung sai".

Hợp đồng mã thay đổi phần nào, vì có tất cả các tùy chọn cho những gì được giữ nguyên tại thời gian thực thi và trình kiểm tra tĩnh có thể giúp chứng minh rằng bạn sẽ không gặp phải trạng thái đó. Tuy nhiên, bạn vẫn cần chọn chính sách thời gian thực hiện ...

1

Bạn có thể sử dụng phương thức Trace.Assert, sẽ hoạt động trên các bản phát hành (nếu bạn đã xác định biểu tượng biên dịch TRACE). . Bạn cũng có thể tùy chỉnh cách ứng dụng của bạn phản ứng trên các lỗi xác nhận theo cách của TraceListener. Mặc định là (không ngạc nhiên) là DefaultTraceListener, sẽ hiển thị xác nhận trong hộp thoại nếu ứng dụng đang chạy ở chế độ tương tác. Ví dụ, nếu bạn muốn ném một ngoại lệ, bạn có thể tự tạo TraceListener và ném nó vào phương thức Fail. Sau đó, bạn có thể xóa DefaultTraceListener và sử dụng của riêng bạn, hoặc programmatically hoặc trong configuration file.

Điều này có vẻ như rất nhiều rắc rối, và chỉ chính đáng nếu bạn muốn tự động thay đổi cách ứng dụng của bạn xử lý các xác nhận theo cách của trình theo dõi. Đối với các vi phạm mà bạn luôn muốn thất bại, hãy tạo lớp học AssertionException của riêng bạn và ném ngay lập tức.

Đối với .NET 4.0, tôi chắc chắn sẽ xem xét phương thức Contract.Assert. Tuy nhiên, phương pháp này chỉ được biên dịch khi các ký hiệu DEBUG hoặc CONTRACTS_FULL được xác định. DEBUG sẽ không hoạt động đối với bản phát hành bản phát hành và CONTRACTS_FULL cũng sẽ bật tất cả các hợp đồng kiểm tra khác, một số trong đó bạn có thể không muốn có mặt trong bản phát hành bản phát hành.

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