Sử dụng NotIm HiệnedException

15

Có được coi là thực hành xấu để ném NotImplementedExceptionmã mà bạn chưa viết? Có thể bình luận TODO sẽ được coi là an toàn hơn?

— Tom Squires
nguồn

6

Điều gì sẽ là nhược điểm của việc sử dụng các ngoại lệ như vậy với bạn?

— SRKX

@SRKX Có nguy cơ ngoại lệ xâm nhập vào mã sản xuất và khiến toàn bộ khối mã không hoạt động. (chưa xảy ra với tôi nhưng tất cả chúng ta đều có ngày nghỉ) Cá nhân tôi sử dụng chúng, tôi đã lo lắng rằng tôi có thể bỏ qua một số nhược điểm.

— Tom Squires

Thật kỳ lạ, không có thẻ nào chỉ định ngôn ngữ nào đang được sử dụng. Điều này không áp dụng cho mọi ngôn ngữ chung, vì C không có bất kỳ loại ngoại lệ nào. Có chỗ cho một thẻ ngôn ngữ ở đây, các bạn.

— David Thornley

1

@DavidThornley, câu hỏi ban đầu được gắn thẻ là C #, vì vậy tôi đã gắn lại thẻ.

— Svick

@svick: Nghĩ rằng đó có khả năng là C #. Cảm ơn đã thêm thẻ.

— David Thornley

34

Tôi tin rằng NotImplementedExceptionthực sự là một thực hành tốt.

Thật vậy, nếu bạn quên thực hiện một phương thức và bạn sử dụng nó sau này trong dự án của bạn (và tin tôi đi, nó sẽ xảy ra), bạn có thể mất một thời gian dài để tìm kiếm những gì đã đi sai từng bước. Nếu bạn có ngoại lệ, chương trình sẽ dừng trực tiếp, nhắc ngoại lệ (nếu bạn bắt ngoại lệ, bạn sẽ tìm thấy nó nhanh chóng bằng cách xem ngoại lệ nào bạn bắt được).

Tôi khuyên bạn nên sử dụng NotImplementedException kết hợp với các nhận xét TODO, theo cách bạn kết hợp trợ giúp GUI (với các tác vụ trong VS) và an toàn chương trình.

Đối với phiên bản phát hành, theo tôi, nó thậm chí còn quan trọng hơn, vì trong hầu hết các trường hợp, bạn thích chương trình của mình bị sập hơn là chương trình rõ ràng hoạt động bình thường nhưng tạo ra kết quả sai.

— SRKX
nguồn

6

Nếu bạn sử dụng Resharper, nó hiển thị NotImplementedExceptions giống như nhận xét của TODO. Tôi nghĩ đó là một tính năng tốt.

— Svick

1

Tham gia một số thực hành TDD tốt và bạn đã có một người chiến thắng

— LRE

7

Nó phụ thuộc vào triết lý chung của bạn xung quanh lỗi và xử lý lỗi. Tôi là kiểu người "lỗi cứng": Tôi sẽ đưa ra một ngoại lệ với gợi ý nhỏ nhất rằng có thể có gì đó không ổn; Tôi sẽ khẳng định mọi thứ; Nếu có một lỗi, nếu một cái gì đó được dự kiến sẽ ở đó, và nó không, hoặc nếu có một cái gì đó ở đó, và nó không nên, toàn bộ vũ trụ phải dừng lại. Tiếng kêu của cửa sổ phải vang lên qua loa.

Có những người khác không muốn bị làm phiền với lỗi. Vậy điều gì sẽ xảy ra nếu chúng tôi gửi nó cho khách hàng và toàn bộ mô-đun báo cáo bị thiếu vì chúng tôi quên mã hóa nó và không ai trong thử nghiệm nhận ra điều đó, vì ứng dụng quá im lặng về nó? Không nên làm gì hơn là ném một ngoại lệ vào mặt khách hàng!

— Mike Nakis
nguồn

Như thể bạn muốn có các hành vi khác nhau trong Gỡ lỗi và Phát hành, và một xác nhận sẽ không luôn luôn cắt nó. Tôi tin rằng Hợp đồng Mã .Net có thể bị tắt trong Bản phát hành.

— Công việc

1

Tôi chủ yếu sử dụng các xác nhận, cũng bị tắt trong phát hành. Tôi có chức năng xác nhận của riêng mình, nó đạt đến một điểm dừng trong gỡ lỗi, đưa ra một ngoại lệ khi kiểm tra hoặc thậm chí không biên dịch khi phát hành.

— Mike Nakis

3

Tôi muốn nói rằng đó là một ý tưởng tốt. Thông thường tôi thấy những ngoại lệ được ném bởi mã bộ xương được tạo tự động từ một biểu mẫu hoặc sơ đồ hoặc một cái gì đó. Ngoại lệ nhắc nhở tôi thực hiện mã và nó đảm bảo rằng sẽ có lỗi nếu tôi cố gắng sử dụng chức năng đã được thiết lập nhưng không bao giờ được thực hiện đầy đủ. Đôi khi tôi sẽ loại bỏ nó hoặc thay thế nó bằng một cái gì đó ít có khả năng tạm dừng thực thi (chẳng hạn như in cảnh báo lên bàn điều khiển), nhưng tôi thấy rằng nó hoạt động với tôi.

Nếu bạn đang xây dựng một thư viện mà những người khác sẽ sử dụng có ngoại lệ này tốt hơn so với giải pháp thay thế, đó sẽ là người dùng thư viện của bạn gọi một hàm và tự hỏi tại sao dường như không có gì xảy ra. Tất nhiên, vẫn còn khá tệ khi có ngoại lệ này trong một thư viện được vận chuyển nhưng tốt hơn là thất bại thầm lặng, IMO.

— Thất vọngWithFormsDesigner
nguồn

1

Tôi nghĩ rằng đó là thực hành tốt. Sự thay thế là tuyên truyền một giá trị hoặc trạng thái không hợp lệ, điều này sẽ ảnh hưởng đến cả mã thử nghiệm và mã sản xuất.

— Larry OBrien
nguồn

1

Đợi đã .... ý bạn là, nơi bạn làm việc, mã ném NotImpl sẽ biến nó thành QA? Ngay cả vào sản xuất?

— Steven Evers

3

Không, ngược lại: NotImpl là một điều kiện lỗi / cờ đỏ rất lớn. Nhưng các TODO không có giá trị ngữ nghĩa và có thể đưa nó vào thử nghiệm hoặc sản xuất, lặng lẽ làm hỏng mọi thứ. (Tôi có thể tưởng tượng một chính sách loại bỏ TODO khỏi sản xuất, nhưng chúng tôi không có quy tắc như vậy.)

— Larry OBrien

1

Tôi luôn luôn sử dụng NotImplementedException- đó là những gì nó làm, sau tất cả.

Điều này có liên quan đến khái niệm "thất bại nhanh": nếu mã của bạn bị ném ngoại lệ, điều đó sẽ bị bắt trước khi đi vào sản xuất. Nếu nó được đưa vào sản xuất, thì ít nhất khách hàng biết rằng lắp ráp không chính xác .

Nếu mã trả về một giá trị vô nghĩa hoặc, đối với voidcác phương thức, không có hành động, thì người tiêu dùng mã của bạn có thể nghĩ rằng cuộc gọi đó có ý nghĩa khi không thực hiện. Sau đó, sau đó, khi họ nhận được một số mã chính xác, mã của họ có thể bị hỏng vì nó phụ thuộc vào hành vi không chính xác trước đây.

— phoog
nguồn

0

Đây là loại dự án gì? Làm việc hay ở nhà? Ở nhà, làm bất cứ điều gì bạn muốn - bất cứ điều gì tốt nhất nhắc nhở bạn rằng bạn cần hoàn thành bất cứ điều gì bạn đang làm.

Trong công việc, viết xong nó.

Tôi không thể thấy tình huống tôi sẽ kiểm tra mã có thể / sẽ phá vỡ các nhà phát triển khác, QA hoặc bản dựng.

— Steven Evers
nguồn

Cả hai, tôi cũng cố gắng tuân thủ các thực hành tốt ở nhà.

— Tom Squires

0

Tôi làm cả tôi nhưng một \ todo trong quá trình tự động hóa doxygene của tôi và sau đó ném ngoại lệ. Theo cách đó, nếu mọi người không thể bị làm phiền với RTFM thì ít nhất họ sẽ có thể tìm ra lý do tại sao chương trình của họ bị sập, thay vì tự hỏi tại sao có một hàm khai báo không trả về giá trị logic.

— thật tuyệt
nguồn