나는 C ++ 프로그램이 궁극적으로 모든 예외를 잡아야한다는 조언을 받았다. 당시의 추론은 본질적으로 예외가 main()이상한 좀비 상태 로 들어가 도록 허용하는 프로그램이었습니다 . 나는 몇 년 전에 이것을 들었고, 되돌아 보면 관찰 된 현상은 문제의 프로젝트에서 매우 큰 코어 덤프의 긴 생성으로 인한 것이라고 생각합니다.
당시 이것은 기괴하지만 설득력이있는 것처럼 보였다. C ++이 모든 예외를 잡아 내지 않은 것에 대해 프로그래머를 "처벌"해야한다는 것은 전적으로 무의미한 일이지만, 내 앞의 증거는 이것을 뒷받침하는 것처럼 보였다. 문제의 프로젝트에서 포착되지 않은 예외를 던진 프로그램은 이상한 좀비 상태로 들어가는 것처럼 보였습니다. 또는 원인이 지금 의심되는 것처럼 원치 않는 코어 덤프 중 프로세스는 비정상적으로 중지하기가 어렵습니다.
(이 시점에서 왜 이것이 더 명확하지 않은지 궁금한 사람은 프로젝트가 여러 프로세스에서 여러 파일로 많은 양의 출력을 생성하여 모든 종류의 aborted (core dumped)메시지 를 효과적으로 모호하게 했으며이 경우 코어 덤프에 대한 사후 검사는 없었습니다. "중요한 디버깅 기술이 아니기 때문에 코어 덤프에 대해서는 많은 생각이 없었습니다. 프로그램 문제는 일반적으로 오래 지속되는 프로그램에 의해 시간이 지남에 따라 많은 이벤트에서 누적 된 상태에 의존하지 않고 짧은 실행 프로그램에 대한 초기 입력 (< 1 시간) 그래서 더 많은 정보를 얻기 위해 디버그 빌드 또는 디버거에서 동일한 입력으로 프로그램을 다시 실행하는 것이 더 실용적이었습니다.)
현재 예외를 남기지 않기위한 목적으로 만 예외를 포착하는 데 큰 이점이 있는지 여부는 확실하지 않습니다 main().
예외가 과거 main()에 발생했을 때 생각할 수있는 작은 이점 은 결과가 std::exception::what()터미널에 인쇄된다는 것입니다 (최소한 Linux에서는 gcc 컴파일 프로그램 사용). 반면에,이 대신에서 파생 된 모든 예외를 잡기에 의해 달성하기 위해 사소한 std::exception및 결과 인쇄 std::exception::what()하고에서 파생되지 않는 예외의 메시지 인쇄하는 것이 바람직의 경우 std::exception가 그 다음 해야한다 떠나기 전에 잡힐 main()인쇄에 위해를 메시지.
예외가 과거에 발생하도록 허용 할 때 생각할 수있는 약간의 단점 main()은 원치 않는 코어 덤프가 생성 될 수 있다는 것입니다. 많은 양의 메모리를 사용하는 프로세스의 경우 이는 상당히 성 가실 수 있으며 프로그램에서 코어 덤핑 동작을 제어하려면 OS 별 함수 호출이 필요합니다. 한편, 코어 덤프 및 종료가 필요한 경우, 대신 호출 std::abort()하여 언제든지이를 달성 할 수 있고 코어 덤프없이 종료를 호출하여 언제든지 호출 할 수 있습니다 std::exit().
일화 적으로, 나는 what(): ...충돌 할 때 널리 배포 된 프로그램에 의해 인쇄되는 기본 메시지를 본 적이 없다고 생각 합니다.
C ++ 예외가 과거에 거품을 일으킨다는 강력한 논쟁은 무엇입니까 main()?
편집 : 이 사이트에는 일반적인 예외 처리 관련 질문이 많이 있습니다. 내 질문은 구체적으로 처리 할 수 없어 C ++ 예외에 관한 main()것입니다. 오류 메시지가 인쇄 될 수는 있지만 즉시 중지 오류가 표시됩니다.