Tại sao các thông số kỹ thuật ngoại lệ xấu?

Trở lại trường khoảng 10+ năm trước, họ đã dạy bạn sử dụng các công cụ xác định ngoại lệ. Vì nền tảng của tôi là một trong số những lập trình viên Torvaldish C, những người ngoan cố tránh C ++ trừ khi bị ép buộc, tôi chỉ kết thúc bằng C ++ một cách rời rạc, và khi tôi vẫn sử dụng các công cụ xác định ngoại lệ vì đó là những gì tôi được dạy.

Tuy nhiên, phần lớn các lập trình viên C ++ dường như cau mày với các nhà đầu cơ ngoại lệ. Tôi đã đọc các cuộc tranh luận và các lập luận từ các bậc thầy C ++ khác nhau, như thế này . Theo như tôi hiểu, nó hiểu rõ ba điều:

1. Các nhà xác định ngoại lệ sử dụng một hệ thống loại không phù hợp với phần còn lại của ngôn ngữ ("hệ thống loại bóng").
2. Nếu chức năng của bạn với một công cụ xác định ngoại lệ ném bất cứ thứ gì khác ngoại trừ những gì bạn đã chỉ định, chương trình sẽ bị chấm dứt theo những cách không mong muốn.
3. Thông số ngoại lệ sẽ bị xóa trong tiêu chuẩn C ++ sắp tới.

Tôi đang thiếu một cái gì đó ở đây hay đây là tất cả những lý do?

Ý kiến ​​của riêng tôi:

Về 1): Vậy thì sao. C ++ có lẽ là ngôn ngữ lập trình không nhất quán nhất từng được tạo ra, theo cú pháp. Chúng tôi có các macro, goto / nhãn, nhóm (tích trữ?) Của hành vi không xác định- / không xác định- / xác định thực hiện, các loại số nguyên được xác định kém, tất cả các quy tắc quảng cáo kiểu ẩn, từ khóa trường hợp đặc biệt như bạn bè, tự động , đăng ký, rõ ràng ... Và như vậy. Ai đó có lẽ có thể viết một vài cuốn sách dày về sự kỳ lạ trong C / C ++. Vậy tại sao mọi người phản ứng chống lại sự không nhất quán đặc biệt này, đó là một lỗ hổng nhỏ so với nhiều tính năng nguy hiểm khác của ngôn ngữ?

Về 2): Đó không phải là trách nhiệm của riêng tôi sao? Có rất nhiều cách khác để tôi có thể viết một lỗi nghiêm trọng trong C ++, tại sao trường hợp cụ thể này lại tồi tệ hơn? Thay vì viết throw(int)và sau đó ném Crash_t, tôi cũng có thể tuyên bố rằng hàm của tôi trả về một con trỏ cho int, sau đó tạo một typecast hoang dã, rõ ràng và trả về một con trỏ cho Crash_t. Tinh thần của C / C ++ luôn là để lại phần lớn trách nhiệm cho lập trình viên.

Thế còn lợi thế thì sao? Rõ ràng nhất là nếu hàm của bạn cố gắng ném rõ ràng bất kỳ loại nào ngoài những gì bạn đã chỉ định, trình biên dịch sẽ cung cấp cho bạn một lỗi. Tôi tin rằng tiêu chuẩn là rõ ràng về điều này (?). Lỗi sẽ chỉ xảy ra khi chức năng của bạn gọi các chức năng khác mà lần lượt ném sai loại.

Đến từ một thế giới của các chương trình C nhúng, xác định, tôi chắc chắn muốn biết chính xác những gì một chức năng sẽ ném vào tôi. Nếu có một cái gì đó trong ngôn ngữ hỗ trợ điều đó, tại sao không sử dụng nó? Các lựa chọn thay thế dường như là:

void func() throw(Egg_t);

và

void func(); // This function throws an Egg_t

Tôi nghĩ rằng có một cơ hội lớn mà người gọi bỏ qua / quên thực hiện thử bắt trong trường hợp thứ hai, ít hơn trong trường hợp đầu tiên.

Theo tôi hiểu, nếu một trong hai hình thức này quyết định đột nhiên ném một loại ngoại lệ khác, chương trình sẽ bị sập. Trong trường hợp đầu tiên bởi vì nó không được phép đưa ra một ngoại lệ khác, trong trường hợp thứ hai bởi vì không ai mong muốn nó sẽ ném một Tây Ban NhaInquisition_t và do đó biểu thức đó không bị bắt ở nơi đáng lẽ phải có.

Trong trường hợp sau này, để có một số biện pháp cuối cùng (...) ở mức cao nhất của chương trình, có vẻ không tốt hơn một sự cố chương trình: "Này, ở đâu đó trong chương trình của bạn có một ngoại lệ kỳ lạ, chưa được xử lý . ". Bạn không thể khôi phục chương trình một khi bạn ở xa nơi bị ném ngoại lệ, điều duy nhất bạn có thể làm là thoát khỏi chương trình.

Và theo quan điểm của người dùng, họ không thể quan tâm hơn nếu họ nhận được một hộp thông báo xấu từ HĐH có nội dung "Chương trình bị chấm dứt. Blablabla tại địa chỉ 0x12345" hoặc hộp thông báo xấu từ chương trình của bạn có nội dung "Ngoại lệ chưa được xử lý: lớp của tôi. func.s Something ". Lỗi vẫn còn đó.

Với tiêu chuẩn C ++ sắp tới, tôi không còn lựa chọn nào khác ngoài việc từ bỏ các nhà đầu cơ ngoại lệ. Nhưng tôi thà nghe một số lập luận chắc chắn tại sao họ xấu, thay vì "Đức Pháp vương đã tuyên bố điều đó và vì thế nó là như vậy". Có lẽ có nhiều tranh luận chống lại họ hơn những gì tôi liệt kê, hoặc có lẽ có nhiều điều với họ hơn tôi nhận ra?

Thông số ngoại lệ là xấu vì chúng được thực thi yếu và do đó không thực sự đạt được nhiều và chúng cũng xấu vì chúng buộc thời gian chạy để kiểm tra các ngoại lệ không mong muốn để chúng có thể chấm dứt (), thay vì gọi UB , điều này có thể lãng phí một lượng đáng kể hiệu suất.

Vì vậy, tóm lại, thông số kỹ thuật ngoại lệ không được thực thi đủ mạnh trong ngôn ngữ để thực sự tạo mã bất kỳ an toàn hơn và thực hiện chúng theo quy định là một sự tiêu tốn hiệu suất lớn.

Một lý do không ai sử dụng chúng là vì giả định chính của bạn là sai:

"[Ưu điểm] rõ ràng nhất là nếu hàm của bạn cố gắng ném một cách rõ ràng bất kỳ loại nào khác với những gì bạn đã chỉ định, trình biên dịch sẽ báo lỗi cho bạn."

struct foo {};
struct bar {};

struct test
{
    void baz() throw(foo)
    {
        throw bar();
    }
};

int main()
{
    test x;
    try { x.baz(); } catch(bar &b) {}
}

Chương trình này biên dịch không có lỗi hoặc cảnh báo .

Hơn nữa, mặc dù ngoại lệ đã bị bắt , chương trình vẫn chấm dứt.

Chỉnh sửa: để trả lời một điểm trong câu hỏi của bạn, bắt (...) (hoặc tốt hơn, bắt (std :: exellect &) hoặc lớp cơ sở khác, sau đó bắt (...)) vẫn hữu ích ngay cả khi bạn không biết chính xác những gì đã sai.

Hãy xem xét rằng người dùng của bạn đã nhấn nút menu để "lưu". Trình xử lý cho nút menu mời ứng dụng lưu. Điều này có thể thất bại vì vô số lý do: tệp nằm trên tài nguyên mạng đã biến mất, có tệp chỉ đọc và không thể lưu lại, v.v. Nhưng người xử lý không thực sự quan tâm tại sao lại có lỗi; nó chỉ quan tâm rằng nó thành công hay thất bại. Nếu nó thành công, tất cả đều tốt. Nếu thất bại, nó có thể cho người dùng biết. Bản chất chính xác của ngoại lệ là không liên quan. Hơn nữa, nếu bạn viết mã phù hợp, an toàn ngoại lệ, điều đó có nghĩa là bất kỳ lỗi nào như vậy có thể lan truyền qua hệ thống của bạn mà không đưa nó xuống - ngay cả đối với mã không quan tâm đến lỗi. Điều này làm cho nó dễ dàng hơn để mở rộng hệ thống. Ví dụ: bây giờ bạn lưu thông qua kết nối cơ sở dữ liệu.

Cuộc phỏng vấn này với Anders Hejlsberg khá nổi tiếng. Trong đó, ông giải thích lý do tại sao nhóm thiết kế C # loại bỏ các ngoại lệ được kiểm tra ngay từ đầu. Tóm lại, có hai lý do chính: khả năng phiên bản và khả năng mở rộng.

Tôi biết OP đang tập trung vào C ++ trong khi Hejlsberg đang thảo luận về C #, nhưng những điểm mà Hejlsberg đưa ra cũng hoàn toàn có thể áp dụng cho C ++.