Việc nắm bắt ngoại lệ trong chính (...) có ý nghĩa không?

Question

Tôi tìm thấy một số mã trong một dự án mà trông như thế:

int main(int argc, char *argv[]) 
{ 
    // some stuff 

try { 
    theApp.Run(); 
} catch (std::exception& exc) { 
    cerr << exc.what() << std::endl; 
    exit(EXIT_FAILURE); 
} 
return (EXIT_SUCCESS); 
} 

Tôi không hiểu tại sao các trường hợp ngoại lệ đang được đánh bắt. Nếu không, ứng dụng sẽ đơn giản thoát ra và ngoại lệ sẽ được in.

Bạn có thấy lý do chính đáng nào để bắt ngoại lệ ở đây không?

---

EDIT: Tôi đồng ý rằng bạn nên in lỗi ngoại lệ. Tuy nhiên, nó sẽ không được tốt hơn để rethrow ngoại lệ? Tôi có cảm giác rằng chúng tôi đang nuốt nó ở đây ...

Answer 1

Nếu ngoại lệ không được bắt buộc thì tiêu chuẩn không xác định liệu ngăn xếp có bị bỏ trống hay không. Vì vậy, trên một số nền tảng destructors sẽ được gọi, và trên những người khác chương trình sẽ chấm dứt ngay lập tức. Việc nắm bắt ở cấp cao nhất đảm bảo rằng các destructor luôn được gọi.

Vì vậy, nếu bạn không chạy dưới trình gỡ rối, có thể bạn nên nắm bắt mọi thứ: (...) cũng như std :: exception. Sau đó, mã ứng dụng của bạn có thể làm sạch với RAII ngay cả trên một ngoại lệ chết người. Trong nhiều trường hợp như vậy bạn không thực sự cần phải dọn dẹp, vì hệ điều hành sẽ làm điều đó cho bạn. Nhưng ví dụ bạn có thể muốn ngắt kết nối sạch từ các dịch vụ từ xa nếu có thể và có thể có các tài nguyên bên ngoài quy trình, chẳng hạn như các đường ống/mutexes được đặt tên mà bạn muốn hủy thay vì bị rò rỉ.

Làm lại ngoại lệ trong trường hợp có vẻ như tôi bị hạn chế sử dụng, vì bạn đã mất ngữ cảnh trong đó ban đầu nó bị ném. Tôi giả sử rằng bẫy một ngoại lệ không bị bắt trong trình gỡ lỗi là noisier hơn là chỉ cần đăng nhập các lỗi để std :: cerr, do đó, rethrowing sẽ là di chuyển thông minh nếu có một cơ hội thiếu đăng nhập.

Nếu bạn muốn trình gỡ rối bẫy các điều kiện bất ngờ trong chế độ gỡ lỗi, trong chế độ phát hành, hãy thoát ngoại lệ mà cuối cùng dẫn đến thoát, có nhiều cách khác để thực hiện điều đó. .Ví dụ: bạn có thể sử dụng macro khẳng định. Tất nhiên, điều đó không giúp đỡ với các điều kiện bất ngờ và không thể đoán trước, như trường hợp ngoại lệ phần cứng nếu bạn đang sử dụng SEH trên .NET.

Answer 2

Tại sao bạn nói rằng ngoại lệ sẽ được in? Đây không phải là hành vi điển hình của thời gian chạy C++. Tốt nhất, bạn có thể mong đợi rằng loại của nó được in.

Ngoài ra, chương trình này để lại trạng thái "lỗi", trong khi ngoại lệ có thể gây ra trạng thái chấm dứt thông báo hủy bỏ (tức là có tín hiệu được chỉ ra trong mã thoát).

Answer 3

Đây là khối bắt toàn cầu. Nó được phổ biến để hiển thị một thông điệp tốt đẹp và người dùng hiểu ('Lỗi nội bộ') thay vì một ngoại lệ khó hiểu in ra. Điều này có thể không hiển nhiên từ khối mã cụ thể, nhưng nói chung là một ý tưởng hay.

Answer 4

Thử nắm bắt trong chức năng chính ẩn ngoại lệ khỏi trình gỡ lỗi. Tôi sẽ nói, nó không tốt.

Mặt khác, khách hàng không được dự kiến ​​sẽ có trình gỡ rối, vì vậy việc bắt ngoại lệ rất tốt. Vì vậy, nó là tốt.

Cá nhân, tôi bắt tất cả ngoại lệ trong chức năng chính, khi tạo bản phát hành và tôi không làm điều đó khi xây dựng cấu hình gỡ lỗi.

Answer 5

Hãy xem qua kinh thánh C++, ví dụ: Stroustrup, anh ta có một ví dụ được lặp lại trong lập trình C++ ứng dụng. Lý do là:

int main(void) 
{ 
    try 
    { 
      // your code 
    } 
    catch (/* YourPossibleExceptions i.e. barfs you expect may occur */) 
    { 
    } 
    catch (...) // unexpected errors, so you can exit gracefully 
    { 
    } 
} 

Answer 6

Một ví dụ đơn giản của một tình huống mà chồng không thư giãn:
Why destructor is not called on exception?

Một danh sách các trường hợp ngoại lệ có thể gây ra các ứng dụng để chấm dứt chứ không phải là thư giãn stack.
Why destructor is not called on exception?

Nếu một ngoại lệ không được bắt ở bất kỳ cấp độ và sẽ thoát khỏi main() sau đó thực hiện được phép gọi chấm dứt() đúng hơn là tháo ngăn xếp (có này bắt tôi ngạc nhiên là tốt).

Kết quả là tôi luôn bắt tất cả ngoại lệ trong chính().

int main() 
{ 
    try 
    { 
    } 
    catch(std::exception const& e) 
    { /* LOG */ 
     // optimally rethrow 
    } 
    catch(...) // Catch anything else. 
    { /* LOG */ 
     // optimally rethrow 
    } 
} 

Để giúp khắc phục sự cố khi gỡ lỗi. Xuất phát ngoại lệ của bạn từ std :: exception và sau đó dính điểm ngắt trong hàm tạo cho std :: exception.

Answer 7

Theo thông số kỹ thuật của Windows, main không được phép ném. (thực tế nó kết quả vào thông báo hỏi bạn có muốn gửi báo cáo lỗi cho Microsoft)