문제

저는 언어 표준에 설명된 예외 사양 동작에 크게 의존하는 이전 코드를 작업하고 있습니다.즉, 아래 설명된 형식의 예외 사양 위반 시 std::unexpected()를 호출합니다.

foo() throw(T) { /*...*/ }

Nothrow 사양은 확실히 던지지 않는 것이 보장되어 있습니다만, 던지기(티) 하나는 둘 다 위반될 것으로 예상됩니다. 디자인에 의해 그리고...글쎄요, 표준은 그만큼을 기대하고 이를 처리할 수 있는 메커니즘을 제공하기 때문입니다.

그 이유는 EH를 예외 처리 외에 오류 처리 메커니즘(자체 오류 클래스 계층 구조에 의해 제어됨)으로 사용하기로 한 디자이너의 결정과 관련이 있습니다.EH에 제시된 관용어는 그들의 요구 사항에 밀접하게 매핑되었으며 그들은 최소한의 노력의 길을 택했습니다.이것은 적어도 내가 보는 방식이며 시스템의 크기와 복잡성을 고려할 때 나에게 특별히 충격적이지는 않습니다.

그러나 나는 이제 포함해야 할 임무를 받았습니다. 새로운 기능과 관련 없는 기능 8.0에 도입된 예외 사양과 관련된 표준과의 차이로 인해 코드가 VC++ 9.0에서 예상대로 작동하지 않습니다.(참조: 마이크로소프트)

표준 동작을 강제하는 방법을 찾으려고 노력 중입니다.컴파일러가 폴백을 제공하기를 바랐습니다.그러나 아무것도 없습니다.

운이 좋지 않아서 완전히 개발된 오류 처리 클래스 계층 구조를 사용하여 350,000줄의 코드에서 실행되는 올바르게 작성된 표준 준수 코드를 변경해야 합니까?아니면 std::unexpected() 동작을 강제하는 데 도움이 되는 방법을 생각해 볼 수 있나요?

편집하다:몇 가지 배경 정보를 제공하고 있습니다.문제의 시스템은 4,000명이 조금 넘는 학생이 분산되어 있는 학교를 위한 학년도 달력 생성기입니다. 아직 숫자는 확실하지 않습니다. 6개 학년, 최대 190개 수업, 12개 가상(장거리 교육) 클래스.MINGW는 VC++ 8.0 또는 9.0 이외의 다른 컴파일러와 마찬가지로 의문의 여지가 없습니다.이는 해당 국가의 교육 시스템에 사용되는 소프트웨어와 관련된 규정 때문입니다.

코드에 필요한 변경 사항은 정확히 달력 생성을 위한 매우 다른 스키마를 갖춘 가상 클래스의 도입을 수용하기 위한 것입니다.그러다가 이런 문제에 부딪혔습니다.소프트웨어는 예기치 않은() 매핑(저장 및 복원)과 bad_Exception 매핑을 통해 작업 흐름을 제어하는 ​​수단으로 달력 생성 프로세스의 일부 부분에서 예외 메커니즘을 많이 사용합니다. 이 중 어느 것도 VC++에서는 작동하지 않습니다.순전히 개인적인 메모에 따르면, 비록 완전히 드물더라도 메커니즘이 실제로 매우 우아하다고 생각합니다.그러나 나는 빗나갔다.

도움이 되었습니까?

해결책

언급한 대로 Visual Studio에는 예외 사양을 처리하는 "흥미로운" 방법이 있습니다.

  • throw() 일반적인 의미를 갖습니다(함수는 throw해서는 안 됩니다).
  • 그 밖의 모든 것(예외 사양 없음 포함)은 다음과 같이 해석됩니다. throw(...)

이를 피할 수 있는 방법은 없습니다.그러나 C++ 커뮤니티는 예외 사양이 쓸모없다는 점에 거의 동의합니다.발생한 오류 유형에 대한 런타임 검사가 정말로 필요합니까?아마도 적절한 단위 테스트가 런타임 검사를 대체할 수 있습니다.

다른 팁

저는 Visual C++ 예외 사양 동작이 8.0 이전에도 표준을 준수한 적이 있다고(혹은 그랬다고 주장한 적이 없다고) 믿지 않으므로 응용 프로그램이 어떻게 작동했는지 잘 모르겠습니다.

다음과 같은 변경을 수행하는 것이 가능합니까?

void f() throw(T)
{
    // ...
}

에게:

void f()
{
    try
    {
        // ...
    }
    catch (T)
    {
        throw;
    }
    catch (...)
    {
        app_unexpected();
    }
}
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top