Tôi có nên kế thừa từ std :: exception không?

Tôi đã thấy ít nhất một nguồn đáng tin cậy (một lớp C ++ tôi đã học) khuyên rằng các lớp ngoại lệ dành riêng cho ứng dụng trong C ++ nên kế thừa từ đó std::exception. Tôi không rõ về lợi ích của phương pháp này.

Trong C #, lý do kế thừa từ ApplicationExceptionrất rõ ràng: bạn nhận được một số phương thức, thuộc tính và hàm tạo hữu ích và chỉ cần thêm hoặc ghi đè những gì bạn cần. Với std::exceptiondường như tất cả các bạn nhận được là một what()phương pháp để ghi đè lên, mà bạn có thể chỉ cần cũng tạo cho mình.

Vì vậy, những lợi ích, nếu có, của việc sử dụng std::exceptionlàm lớp cơ sở cho lớp ngoại lệ dành riêng cho ứng dụng của tôi là gì? Có bất kỳ lý do chính đáng nào để không thừa kế từ đó std::exceptionkhông?

Lợi ích chính là mã sử dụng lớp học của bạn không nhất thiết phải biết loại chính xác những gì bạn throwở đó, nhưng có thể chỉ là catchsự std::exception.

Chỉnh sửa: như Martin và những người khác đã lưu ý, bạn thực sự muốn dẫn xuất từ ​​một trong các lớp con của được std::exceptionkhai báo trong <stdexcept>tiêu đề.

Vấn đề std::exceptionlà không có hàm tạo nào (trong các phiên bản tuân thủ tiêu chuẩn) chấp nhận một thông báo.

Kết quả là tôi thích bắt nguồn từ đó std::runtime_error. Điều này có nguồn gốc từ std::exceptionnhưng các hàm tạo của nó cho phép bạn truyền C-String hoặc a std::stringđến hàm tạo sẽ được trả về (dưới dạng a char const*) khi what()được gọi.

Lý do kế thừa từ std::exceptionđó là lớp cơ sở "chuẩn" cho các trường hợp ngoại lệ, vì vậy, những người khác trong nhóm chẳng hạn, mong đợi điều đó và nắm bắt cơ sở là điều đương nhiênstd::exception .

Nếu bạn đang tìm kiếm sự tiện lợi, bạn có thể kế thừa từ hàm std::runtime_errortạo cung cấp đó std::string.

Tôi đã từng tham gia dọn dẹp một cơ sở mã lớn nơi mà các tác giả trước đó đã ném ints, HRESULTS, std :: string, char *, random class ... những thứ khác nhau ở khắp mọi nơi; chỉ cần đặt tên một loại và nó có thể đã bị ném ở đâu đó. Và không có lớp cơ sở chung nào cả. Tin tôi đi, mọi thứ gọn gàng hơn nhiều khi chúng ta đến mức tất cả các loại ném đều có một cơ sở chung mà chúng ta có thể nắm bắt và biết rằng sẽ không có gì vượt qua. Vì vậy, hãy làm cho bản thân bạn (và những người sẽ phải duy trì mã của bạn trong tương lai) và làm theo cách đó ngay từ đầu.

Bạn nên kế thừa từ boost :: exception . Nó cung cấp nhiều tính năng hơn và các cách dễ hiểu để mang dữ liệu bổ sung ... tất nhiên, nếu bạn không sử dụng Boost , thì hãy bỏ qua gợi ý này.

Có bạn nên bắt nguồn từ std::exception.

Những người khác đã trả lời rằng std::exceptioncó vấn đề là bạn không thể chuyển một tin nhắn văn bản đến nó, tuy nhiên, nói chung không phải là một ý kiến ​​hay khi cố gắng định dạng một tin nhắn của người dùng tại thời điểm ném. Thay vào đó, hãy sử dụng đối tượng ngoại lệ để vận chuyển tất cả thông tin có liên quan đến địa điểm bắt, sau đó có thể định dạng một thông báo thân thiện với người dùng.

Lý do tại sao bạn có thể muốn kế thừa từ std::exceptionlà vì nó cho phép bạn ném một ngoại lệ được bắt theo lớp đó, tức là:

class myException : public std::exception { ... };
try {
    ...
    throw myException();
}
catch (std::exception &theException) {
    ...
}

Có một vấn đề với sự kế thừa mà bạn nên biết là việc cắt đối tượng. Khi bạn viết throw e;một biểu thức ném sẽ khởi tạo một đối tượng tạm thời, được gọi là đối tượng ngoại lệ, loại của đối tượng này được xác định bằng cách loại bỏ bất kỳ định tính cv cấp cao nhất nào khỏi kiểu tĩnh của toán hạng throw. Đó có thể không phải là những gì bạn đang mong đợi. Ví dụ về vấn đề bạn có thể tìm thấy ở đây .

Nó không phải là một lập luận chống lại sự kế thừa, nó chỉ là thông tin 'phải biết'.

Sự khác biệt: std :: runtime_error so với std :: exception ()

Bạn có nên thừa kế từ nó hay không là tùy thuộc vào bạn. Tiêu chuẩn std::exceptionvà hậu duệ tiêu chuẩn của nó đề xuất một cấu trúc có thể phân cấp ngoại lệ (phân chia thành logic_errorsubhierarchy và runtime_errorsubhierarchy) và một giao diện đối tượng ngoại lệ có thể. Nếu bạn thích nó - hãy sử dụng nó. Nếu vì lý do nào đó bạn cần một thứ gì đó khác biệt - hãy xác định khung ngoại lệ của riêng bạn.

Vì ngôn ngữ này đã ném std :: exception, nên bạn vẫn cần nắm bắt nó để cung cấp báo cáo lỗi phù hợp. Bạn cũng có thể sử dụng cùng một cách bắt cho tất cả các trường hợp ngoại lệ không mong muốn của riêng bạn. Ngoài ra, hầu hết bất kỳ thư viện nào ném các ngoại lệ sẽ lấy chúng từ std :: exception.

Nói cách khác,

catch (...) {cout << "Unknown exception"; }

hoặc là

catch (const std::exception &e) { cout << "unexpected exception " << e.what();}

Và lựa chọn thứ hai chắc chắn tốt hơn.

Nếu tất cả các ngoại lệ có thể có của bạn bắt nguồn từ đó std::exception, khối bắt của bạn có thể đơn giản catch(std::exception & e)và yên tâm nắm bắt mọi thứ.

Khi bạn đã nắm bắt được ngoại lệ, bạn có thể sử dụng whatphương pháp đó để nhận thêm thông tin. C ++ không hỗ trợ gõ kiểu vịt, vì vậy một lớp khác với một whatphương thức sẽ yêu cầu một hàm bắt khác và mã khác để sử dụng nó.

Câu hỏi đầu tiên có nên suy ra từ bất kỳ loại ngoại lệ chuẩn nào hay không. Làm như vậy cho phép một trình xử lý ngoại lệ duy nhất cho tất cả các ngoại lệ thư viện tiêu chuẩn và của riêng bạn, nhưng nó cũng khuyến khích các trình xử lý bắt tất cả như vậy. Vấn đề là người ta chỉ nên bắt những trường hợp ngoại lệ mà người ta biết cách xử lý. Ví dụ: trong main (), việc bắt tất cả std :: exceptions có thể là một điều tốt nếu chuỗi what () sẽ được ghi lại như một phương sách cuối cùng trước khi thoát. Tuy nhiên, ở những nơi khác, nó không chắc là một ý kiến ​​hay.

Khi bạn đã quyết định có nên lấy từ loại ngoại lệ tiêu chuẩn hay không, thì câu hỏi đặt ra là loại nào nên là cơ sở. Nếu ứng dụng của bạn không cần i18n, bạn có thể nghĩ rằng việc định dạng một tin nhắn tại địa chỉ cuộc gọi cũng tốt như lưu thông tin và tạo tin nhắn tại địa chỉ cuộc gọi. Vấn đề là thông báo được định dạng có thể không cần thiết. Tốt hơn nên sử dụng lược đồ tạo thông báo lười biếng - có lẽ với bộ nhớ được phân bổ trước. Sau đó, nếu tin nhắn là cần thiết, nó sẽ được tạo khi truy cập (và có thể được lưu trong bộ nhớ cache trong đối tượng ngoại lệ). Do đó, nếu thông báo được tạo ra khi được ném, thì cần có một dẫn xuất ngoại lệ std ::, như std :: runtime_error làm lớp cơ sở. Nếu thông báo được tạo một cách lười biếng, thì std :: exception là cơ sở thích hợp.

Một lý do khác cho các ngoại lệ của lớp con là khía cạnh thiết kế tốt hơn khi làm việc trên các hệ thống đóng gói lớn. Bạn có thể sử dụng lại nó cho những thứ như thông báo xác thực, truy vấn người dùng, lỗi bộ điều khiển nghiêm trọng, v.v. Thay vì viết lại hoặc gọi lại tất cả xác thực của bạn như thông báo, bạn có thể chỉ cần "bắt" nó trên tệp nguồn chính, nhưng hãy ném lỗi vào bất kỳ đâu trong toàn bộ tập hợp các lớp của bạn.

Ví dụ: Một ngoại lệ nghiêm trọng sẽ kết thúc chương trình, một lỗi xác thực sẽ chỉ xóa ngăn xếp và truy vấn người dùng sẽ hỏi người dùng cuối một câu hỏi.

Làm theo cách này cũng có nghĩa là bạn có thể sử dụng lại các lớp giống nhau nhưng trên các giao diện khác nhau. Ví dụ: Một ứng dụng windows có thể sử dụng hộp thông báo, một dịch vụ web sẽ hiển thị html và hệ thống báo cáo sẽ ghi nhật ký nó, v.v.

Mặc dù câu hỏi này khá cũ và đã được trả lời nhiều, tôi chỉ muốn thêm một lưu ý về cách xử lý ngoại lệ thích hợp trong C ++ 11, vì tôi liên tục thiếu điều này trong các cuộc thảo luận về ngoại lệ:

Sử dụng std::nested_exceptionvàstd::throw_with_nested

Nó được mô tả trên StackOverflow ở đây và đây , cách bạn có thể lấy lại dấu vết về các ngoại lệ bên trong mã của mình mà không cần trình gỡ lỗi hoặc ghi nhật ký rườm rà, bằng cách viết một trình xử lý ngoại lệ thích hợp sẽ tạo lại các ngoại lệ lồng nhau.

Vì bạn có thể làm điều này với bất kỳ lớp ngoại lệ dẫn xuất nào, bạn có thể thêm nhiều thông tin vào một backtrace như vậy! Bạn cũng có thể xem qua MWE của tôi trên GitHub , nơi mà backtrace sẽ trông giống như sau:

Library API: Exception caught in function 'api_function'
Backtrace:
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt"

Bạn thậm chí không cần phải phân lớp std::runtime_errorđể có nhiều thông tin khi một ngoại lệ được đưa ra.

Lợi ích duy nhất mà tôi thấy trong phân lớp (thay vì chỉ sử dụng std::runtime_error) là trình xử lý ngoại lệ của bạn có thể bắt ngoại lệ tùy chỉnh của bạn và làm điều gì đó đặc biệt. Ví dụ:

try
{
  // something that may throw
}
catch( const MyException & ex )
{
  // do something specialized with the
  // additional info inside MyException
}
catch( const std::exception & ex )
{
  std::cerr << ex.what() << std::endl;
}
catch( ... )
{
  std::cerr << "unknown exception!" << std::endl;
}