예외 사양이 나쁜 이유는 무엇입니까?

약 10 년 전에 학교로 돌아와서 예외 지정자를 사용하도록 가르치고있었습니다. 내 배경은 그들 중 하나이기 때문에 강제하지 않으면 C ++을 완고하게 피하는 Torvaldish C 프로그래머이기 때문에 나는 C ++로만 끝나고 내가 할 때 예외 지정자를 계속 사용합니다.

그러나 대부분의 C ++ 프로그래머는 예외 지정자를 찌푸리는 것처럼 보입니다. 나는 이와 같은 다양한 C ++ 전문가들의 토론과 논쟁을 읽었다 . 내가 이해하는 한 세 가지로 요약합니다.

1. 예외 지정자는 나머지 언어와 일치하지 않는 유형 시스템 ( "그림자 유형 시스템")을 사용합니다.
2. 예외 지정자를 가진 함수가 지정한 것을 제외한 다른 것을 던지면 프로그램이 예기치 않은 나쁜 방식으로 종료됩니다.
3. 향후 C ++ 표준에서는 예외 지정자가 제거됩니다.

여기에 뭔가 빠졌습니까? 아니면 모든 이유입니까?

내 의견 :

1)에 관해서 : 그래서 무엇. C ++은 아마도 문법적으로 가장 일관성이없는 프로그래밍 언어 일 것입니다. 우리는 매크로, goto / labels, undefined / unspecified / implementation-defined behavior의 horde (hoard?), 잘못 정의 된 정수 타입, 모든 암시 적 타입 프로모션 규칙, friend, auto와 같은 특수한 키워드를 가지고 있습니다. , 등록, 명시 적 ... 등등. 누군가 C / C ++에서 모든 이상한 점을 담은 두꺼운 책 몇 권을 쓸 수도 있습니다. 그렇다면 왜 사람들은이 특정한 불일치에 대해 반응합니까? 언어의 훨씬 더 위험한 다른 특징들과 비교할 때 사소한 결함입니까?

2) 관련 : 본인의 책임이 아닙니까? C ++에서 치명적인 버그를 작성할 수있는 다른 많은 방법이 있습니다.이 특별한 경우가 더 나쁜 이유는 무엇입니까? throw(int)Crash_t 를 작성 하고 던지는 대신 내 함수가 int에 대한 포인터를 반환한다고 주장 할 수 있습니다. C / C ++의 정신은 항상 대부분의 책임을 프로그래머에게 맡기는 것이 었습니다.

그렇다면 이점은 어떻습니까? 가장 분명한 것은 함수가 지정한 것과 다른 유형을 명시 적으로 던지려고하면 컴파일러에서 오류를 발생 시킨다는 것입니다. 나는 이것에 관해 표준이 명확하다고 생각합니다 (?). 버그는 함수가 다른 함수를 호출하여 잘못된 유형을 던질 때만 발생합니다.

결정 론적 임베디드 C 프로그램의 세계에서 왔을 때, 나는 함수가 무엇을 던질 지 정확히 알고 싶어합니다. 그것을 지원하는 언어로 된 것이 있다면 왜 사용하지 않습니까? 대안은 다음과 같습니다.

void func() throw(Egg_t);

과

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

호출자가 두 번째 경우에는 try-catch를 구현하는 것을 무시 / 잊어 버릴 가능성이 높지만 첫 번째 경우는 적습니다.

내가 알기로,이 두 가지 형식 중 하나가 갑자기 다른 종류의 예외를 던지기로 결정하면 프로그램이 중단됩니다. 첫 번째 경우에는 다른 예외를 던질 수 없기 때문에 두 번째 경우 아무도 SpanishInquisition_t를 던질 것으로 예상하지 않았으므로 표현식이 있어야 할 곳에서 잡히지 않기 때문입니다.

후자의 경우, 프로그램의 최상위 레벨에서 최후의 어획량 캐치 (...)를 갖는 것이 실제로 프로그램 충돌보다 더 나은 것처럼 보이지는 않습니다. "프로그램의 어딘가에 무언가 처리되지 않은 예외가 발생했습니다 ". 예외가 발생한 곳에서 멀어지면 프로그램을 복구 할 수 없습니다. 프로그램을 종료하는 것이 유일한 방법입니다.

그리고 사용자의 관점에서 그들은 "프로그램이 종료되었습니다. 주소 0x12345의 Blablabla"라는 메시지 나 OS에서 "처리되지 않은 예외 : myclass. func.something "을 참조하십시오. 버그는 여전히 존재합니다.

다가오는 C ++ 표준을 사용하면 예외 지정자를 포기하는 것 외에 다른 옵션이 없습니다. 그러나 나는 "그의 거룩함이 말 했으므로 그렇게 나쁜 것"보다는 그들이 왜 나쁜지에 대한 확실한 주장을 듣고 싶습니다. 아마도 내가 열거 한 것보다 더 많은 주장이 있거나, 내가 아는 것보다 더 많은 주장이 있습니까?

예외 사양은 약하게 시행되어 실제로 많은 것을 달성하지 못하기 때문에 좋지 않습니다. 런타임에서 UB를 호출하는 대신 종료 () 할 수 있도록 예기치 않은 예외를 검사하도록 강제하기 때문에 나쁩니다. 이로 인해 상당한 양의 성능이 낭비 될 수 있습니다.

요약하면 예외 코드는 실제로 코드를 더 안전하게 만들 정도로 언어에 강하게 적용되지 않았으며 지정된대로 구현하면 성능이 크게 저하되었습니다.

아무도 사용하지 않는 한 가지 이유는 기본 가정이 잘못 되었기 때문입니다.

"가장 명백한 [이점]은 함수가 사용자가 지정한 것과 다른 유형을 명시 적으로 던지려고하면 컴파일러가 오류를 발생 시킨다는 것입니다."

struct foo {};
struct bar {};

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

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

이 프로그램은 오류나 경고없이 컴파일됩니다 .

또한 예외가 발생하더라도 프로그램은 여전히 ​​종료됩니다.

편집 : 질문의 특정 부분에 대답하려면 catch (...) (또는 더 나은 catch (std :: exeption &) 또는 기타 기본 클래스를 누른 다음 catch (...))는 여전히 유용하지 않습니다. 무엇이 잘못되었는지 정확히 알고 있습니다.

사용자가 "저장"메뉴 버튼을 쳤다고 가정하십시오. 메뉴 버튼의 핸들러는 애플리케이션을 저장하도록 초대합니다. 파일이 사라진 네트워크 리소스에 있고, 읽기 전용 파일이 있고, 파일을 저장할 수없는 등의 이유로 여러 가지 이유로 실패 할 수 있습니다. 그러나 처리기는 실제로 실패한 이유를 신경 쓰지 않습니다. 그것은 단지 성공 또는 실패를 신경 쓰는 것입니다. 성공하면 모든 것이 좋습니다. 실패하면 사용자에게 알릴 수 있습니다. 예외의 정확한 특성은 관련이 없습니다. 또한, 예외가없는 적절한 코드를 작성하면 오류를 신경 쓰지 않는 코드의 경우에도 이러한 오류가 발생하지 않고 시스템을 통해 전파 될 수 있습니다. 이를 통해 시스템을보다 쉽게 ​​확장 할 수 있습니다. 예를 들어, 이제 데이터베이스 연결을 통해 저장합니다.

Anders Hejlsberg와의 인터뷰 는 매우 유명합니다. 여기에서 C # 디자인 팀이 먼저 확인 된 예외를 버린 이유를 설명합니다. 간단히 말해 버전 화와 확장 성의 두 가지 주요 이유가 있습니다.

OP는 C ++에 중점을두고 있지만 Hejlsberg는 C #에 대해 논의하고 있지만 Hejlsberg가 만드는 점은 C ++에도 완벽하게 적용됩니다.