Tôi có nên sử dụng công cụ chỉ định ngoại lệ trong C ++ không?

Trong C ++, bạn có thể chỉ định rằng một hàm có thể có hoặc không thể tạo ra một ngoại lệ bằng cách sử dụng một bộ định nghĩa ngoại lệ. Ví dụ:

void foo() throw(); // guaranteed not to throw an exception
void bar() throw(int); // may throw an exception of type int
void baz() throw(...); // may throw an exception of some unspecified type

Tôi nghi ngờ về việc thực sự sử dụng chúng vì những điều sau:

1. Trình biên dịch không thực sự thực thi các chỉ định ngoại lệ theo bất kỳ cách nào nghiêm ngặt, vì vậy lợi ích không lớn. Lý tưởng nhất là bạn muốn gặp lỗi biên dịch.
2. Nếu một hàm vi phạm một chỉ định ngoại lệ, tôi nghĩ hành vi tiêu chuẩn là chấm dứt chương trình.
3. Trong VS.Net, nó coi cú ném (X) là cú ném (...), vì vậy việc tuân thủ tiêu chuẩn là không mạnh.

Bạn có nghĩ rằng các chỉ định ngoại lệ nên được sử dụng?
Vui lòng trả lời bằng "có" hoặc "không" và cung cấp một số lý do để biện minh cho câu trả lời của bạn.

Không.

Dưới đây là một số ví dụ tại sao:

1. Không thể viết mã mẫu với các thông số kỹ thuật ngoại lệ,

   template<class T>
   void f( T k )
   {
        T x( k );
        x.x();
   }

   Các bản sao có thể ném, truyền tham số có thể ném và x()có thể ném một số ngoại lệ không xác định.

2. Thông số kỹ thuật ngoại lệ có xu hướng cấm khả năng mở rộng.

   virtual void open() throw( FileNotFound );

   có thể phát triển thành

   virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive );

   Bạn thực sự có thể viết rằng

   throw( ... )

   Đầu tiên là không thể mở rộng, thứ hai là quá tham vọng và thứ ba thực sự là ý bạn, khi bạn viết các hàm ảo.

3. Mã kế thừa

   Khi bạn viết mã dựa trên một thư viện khác, bạn không thực sự biết nó có thể làm gì khi có sự cố khủng khiếp.

   int lib_f();
   
   void g() throw( k_too_small_exception )
   { 
      int k = lib_f();
      if( k < 0 ) throw k_too_small_exception();
   }

   gsẽ kết thúc, khi lib_f()ném. Đây (trong hầu hết các trường hợp) không phải là điều bạn thực sự muốn. std::terminate()không bao giờ nên được gọi. Luôn tốt hơn nếu để ứng dụng gặp sự cố với một ngoại lệ chưa được xử lý, từ đó bạn có thể truy xuất dấu vết ngăn xếp, hơn là chết một cách âm thầm / dữ dội.

4. Viết mã trả về các lỗi phổ biến và ném vào những trường hợp đặc biệt.

   Error e = open( "bla.txt" );
   if( e == FileNotFound )
       MessageUser( "File bla.txt not found" );
   if( e == AccessDenied )
       MessageUser( "Failed to open bla.txt, because we don't have read rights ..." );
   if( e != Success )
       MessageUser( "Failed due to some other error, error code = " + itoa( e ) );
   
   try
   {
      std::vector<TObj> k( 1000 );
      // ...
   }
   catch( const bad_alloc& b )
   { 
      MessageUser( "out of memory, exiting process" );
      throw;
   }

Tuy nhiên, khi thư viện của bạn chỉ ném các ngoại lệ của riêng bạn, bạn có thể sử dụng các đặc tả ngoại lệ để nêu ý định của mình.

Tránh các đặc tả ngoại lệ trong C ++. Những lý do bạn đưa ra trong câu hỏi của bạn là một khởi đầu khá tốt cho lý do tại sao.

Xem "Cái nhìn thực dụng về các thông số kỹ thuật ngoại lệ" của Herb Sutter .

Tôi nghĩ rằng tiêu chuẩn ngoại trừ quy ước (đối với C ++)
Các chỉ định ngoại lệ là một thử nghiệm trong tiêu chuẩn C ++ hầu như không thành công.
Ngoại lệ là mã xác định không ném là hữu ích nhưng bạn cũng nên thêm khối try catch thích hợp vào nội bộ để đảm bảo mã khớp với mã xác định. Herb Sutter có một trang về chủ đề này. Gotch 82

Ngoài ra, tôi nghĩ rằng nó là giá trị mô tả Bảo đảm Ngoại lệ.

Về cơ bản đây là tài liệu về cách trạng thái của một đối tượng bị ảnh hưởng bởi các ngoại lệ thoát khỏi một phương thức trên đối tượng đó. Thật không may, chúng không được thực thi hoặc được đề cập bởi trình biên dịch.
Tăng cường và Ngoại lệ

Đảm bảo ngoại lệ

Không bảo đảm:

Không có gì đảm bảo về trạng thái của đối tượng sau khi một ngoại lệ thoát khỏi một phương thức
Trong những tình huống này, đối tượng không nên được sử dụng nữa.

Đảm bảo cơ bản:

Trong hầu hết mọi tình huống, đây phải là sự đảm bảo tối thiểu mà một phương pháp cung cấp.
Điều này đảm bảo trạng thái của đối tượng được xác định rõ ràng và vẫn có thể được sử dụng nhất quán.

Đảm bảo mạnh mẽ: (hay còn gọi là Đảm bảo giao dịch)

Điều này đảm bảo rằng phương thức sẽ hoàn tất thành công
Hoặc một Ngoại lệ sẽ được ném ra và trạng thái đối tượng sẽ không thay đổi.

Đảm bảo Không ném:

Phương thức đảm bảo rằng không có ngoại lệ nào được phép truyền ra khỏi phương thức.
Tất cả các trình hủy phải đảm bảo điều này.
| NB Nếu một ngoại lệ thoát khỏi một trình hủy trong khi một ngoại lệ đang lan truyền
| ứng dụng sẽ chấm dứt

gcc sẽ phát ra cảnh báo khi bạn vi phạm các thông số kỹ thuật ngoại lệ. Những gì tôi làm là sử dụng macro để sử dụng các thông số kỹ thuật ngoại lệ chỉ trong chế độ "lint" biên dịch rõ ràng để kiểm tra nhằm đảm bảo các ngoại lệ đồng ý với tài liệu của tôi.

Bộ chỉ định ngoại lệ hữu ích duy nhất là "ném ()", như trong "không ném".

Đặc tả ngoại lệ không phải là công cụ hữu ích tuyệt vời trong C ++. Tuy nhiên, có / có / một cách sử dụng tốt cho chúng, nếu kết hợp với std :: bất ngờ.

Những gì tôi làm trong một số dự án là viết mã với các thông số kỹ thuật ngoại lệ, và sau đó gọi set_uneosystem () với một hàm sẽ tạo ra một ngoại lệ đặc biệt cho thiết kế của riêng tôi. Ngoại lệ này, khi xây dựng, nhận được một dấu vết (theo cách dành riêng cho nền tảng) và có nguồn gốc từ std :: bad_exception (để cho phép nó được truyền bá nếu muốn). Nếu nó gây ra lệnh gọi chấm dứt (), như nó thường xảy ra, backtrace được in bởi what () (cũng như ngoại lệ ban đầu đã gây ra nó; không khó để tìm thấy điều đó) và vì vậy tôi nhận được thông tin về vị trí hợp đồng của tôi vi phạm, chẳng hạn như ngoại lệ thư viện không mong muốn nào đã được ném.

Nếu tôi làm điều này, tôi không bao giờ cho phép phổ biến các ngoại lệ thư viện (ngoại trừ các ngoại lệ std) và lấy tất cả các ngoại lệ của tôi từ std :: exception. Nếu một thư viện quyết định ném, tôi sẽ nắm bắt và chuyển đổi thành hệ thống phân cấp của riêng mình, cho phép tôi luôn kiểm soát mã. Các hàm tạm gọi các hàm phụ thuộc nên tránh các đặc tả ngoại lệ vì những lý do rõ ràng; nhưng rất hiếm khi có một giao diện hàm mẫu với mã thư viện (và rất ít thư viện thực sự sử dụng các mẫu một cách hữu ích).

Nếu bạn đang viết mã sẽ được sử dụng bởi những người thích nhìn vào khai báo hàm hơn bất kỳ nhận xét nào xung quanh nó, thì một đặc tả sẽ cho họ biết những ngoại lệ nào họ có thể muốn nắm bắt.

Nếu không, tôi không thấy nó đặc biệt hữu ích khi sử dụng bất kỳ thứ gì nhưng throw()để chỉ ra rằng nó không ném ra bất kỳ ngoại lệ nào.

Không. Nếu bạn sử dụng chúng và một ngoại lệ được đưa ra mà bạn không chỉ định, bằng mã của bạn hoặc mã được gọi bằng mã của bạn, thì hành vi mặc định là nhanh chóng chấm dứt chương trình của bạn.

Ngoài ra, tôi tin rằng việc sử dụng chúng đã không được chấp nhận trong các bản nháp hiện tại của tiêu chuẩn C ++ 0x.

Đặc tả "throw ()" cho phép trình biên dịch thực hiện một số tối ưu hóa khi thực hiện phân tích luồng mã nếu nó biết rằng hàm sẽ không bao giờ ném ngoại lệ (hoặc ít nhất là hứa hẹn sẽ không bao giờ ném ngoại lệ). Larry Osterman nói ngắn gọn về điều này ở đây:

http://blogs.msdn.com/larryosterman/archive/2006/03/22/558390.aspx

Nói chung tôi sẽ không sử dụng các chỉ định ngoại lệ. Tuy nhiên, trong trường hợp nếu có bất kỳ ngoại lệ nào khác đến từ hàm được đề cập đến mà chương trình chắc chắn không thể sửa được , thì nó có thể hữu ích. Trong mọi trường hợp, hãy đảm bảo ghi lại rõ ràng những ngoại lệ có thể mong đợi từ chức năng đó.

Có, hành vi mong đợi của một ngoại lệ không được chỉ định được ném ra từ một hàm với các mã chỉ định ngoại lệ là gọi cuối cùng ().

Tôi cũng sẽ lưu ý rằng Scott Meyers giải quyết vấn đề này bằng C ++ Hiệu quả hơn. C ++ Hiệu quả và C ++ Hiệu quả hơn của ông là những cuốn sách rất được khuyến khích.

Có, nếu bạn thích tài liệu nội bộ. Hoặc có thể viết một bản libary mà những người khác sẽ sử dụng để họ có thể kể những gì xảy ra mà không cần tham khảo tài liệu. Ném hay không ném có thể được coi là một phần của API, gần giống như giá trị trả về.

Tôi đồng ý, chúng không thực sự hữu ích để thực thi tính đúng đắn kiểu Java trong trình biên dịch, nhưng tốt hơn là không có gì hoặc các bình luận lộn xộn.

Chúng có thể hữu ích cho việc kiểm thử đơn vị để khi viết các bài kiểm tra, bạn biết những gì mong đợi hàm sẽ ném khi nó bị lỗi, nhưng không có thực thi nào xung quanh chúng trong trình biên dịch. Tôi nghĩ rằng chúng là mã bổ sung không cần thiết trong C ++. Điều mà bạn chọn tất cả những gì bạn nên chắc chắn là bạn tuân theo cùng một tiêu chuẩn mã hóa trong toàn bộ dự án và các thành viên trong nhóm để mã của bạn vẫn có thể đọc được.

Từ bài báo:

http://www.boost.org/community/exception_safety.html

“Việc viết một vùng chứa chung chung an toàn cho ngoại lệ là điều ai cũng biết.” Tuyên bố này thường được nghe khi tham chiếu đến một bài báo của Tom Cargill [4] trong đó ông khám phá vấn đề an toàn ngoại lệ cho một mẫu ngăn xếp chung. Trong bài báo của mình, Cargill đưa ra nhiều câu hỏi hữu ích, nhưng tiếc là không đưa ra được giải pháp cho vấn đề của mình. Ông kết luận bằng cách cho rằng một giải pháp có thể không khả thi. Thật không may, bài báo của ông đã được nhiều người đọc như là "bằng chứng" cho suy đoán đó. Kể từ khi nó được xuất bản, đã có rất nhiều ví dụ về các thành phần chung an toàn ngoại lệ, trong số đó có các bộ chứa thư viện chuẩn C ++.

Và thực sự tôi có thể nghĩ ra nhiều cách để làm cho các lớp mẫu ngoại lệ được an toàn. Trừ khi bạn không có quyền kiểm soát tất cả các lớp con thì bạn có thể gặp sự cố. Để làm điều này, người ta có thể tạo các typedef trong các lớp của bạn để xác định các ngoại lệ do các lớp mẫu khác nhau ném ra. Điều này nghĩ rằng vấn đề là luôn luôn sửa chữa nó sau đó thay vì thiết kế nó ngay từ đầu, và tôi nghĩ chính chi phí này mới là rào cản thực sự.

Thông số kỹ thuật ngoại lệ = rác, hãy hỏi bất kỳ nhà phát triển Java nào trên 30 tuổi