std :: exception에서 상속해야합니까?

적어도 하나의 신뢰할 수있는 소스 (내가 취한 C ++ 클래스)에서 C ++의 애플리케이션 별 예외 클래스가 std::exception. 이 접근 방식의 이점에 대해 잘 모르겠습니다.

C #에서 상속하는 이유 ApplicationException는 분명합니다. 유용한 메서드, 속성 및 생성자 몇 가지를 얻고 필요한 항목을 추가하거나 재정의하기 만하면됩니다. 로 std::exception그것은 당신이 얻을 모두가 것 같다 what()당신은 단지뿐만 아니라 자신을 만들 수 있습니다 오버라이드 (override)하는 방법.

그렇다면 std::exception애플리케이션 별 예외 클래스에 대한 기본 클래스로 사용하면 어떤 이점이 있습니까? 상속하지 말아야 할 합당한 이유가 std::exception있습니까?

주요 이점은 무엇을의 정확한 유형을 알고하지 않는 클래스를 사용하여 해당 코드 throw그것에을 할 수 있지만, 단지 . 편집 : Martin과 다른 사람들이 언급했듯이 실제로 헤더 에 선언 된 하위 클래스 중 하나에서 파생하려고합니다 .catchstd::exception

std::exception<stdexcept>

문제 std::exception는 메시지를 수락하는 생성자가 없다는 것입니다 (표준 호환 버전에서).

결과적으로 나는 std::runtime_error. 이것은 파생 std::exception되었지만 생성자를 사용하면 호출 될 때 std::string반환 될 생성자에 C-String 또는 a 를 전달할 수 있습니다 .char const*what()

에서 상속하는 이유는 std::exception예외에 대한 "표준"기본 클래스이므로 팀의 다른 사람들이이를 예상하고 base를 잡는 것은 자연스러운 일입니다 std::exception.

편의를 찾고 있다면 생성자 std::runtime_error를 제공하는 상속을받을 수 있습니다 std::string.

나는 이전의 저자들이 int, HRESULTS, std :: string, char *, random classes ... 모든 곳에서 다른 것들을 던진 대규모 코드베이스 정리에 참여한 적이 있습니다. 유형의 이름을 지정하면 아마도 어딘가에 던져졌을 것입니다. 그리고 공통 기본 클래스가 전혀 없습니다. 저를 믿으십시오. 던져진 모든 유형이 우리가 잡을 수있는 공통 기반을 가지고 있고 아무것도 지나칠 수 없다는 것을 알면 상황이 훨씬 더 깔끔해졌습니다. 그러니 여러분 자신 (그리고 앞으로 여러분의 코드를 유지해야 할 사람들)에게 호의를 베푸시고 처음부터 그렇게하세요.

boost :: exception 에서 상속해야합니다 . 추가 데이터를 전달하는 더 많은 기능과 잘 알려진 방법을 제공합니다. 물론 Boost를 사용하지 않는 경우이 제안을 무시하십시오.

예,에서 파생해야합니다 std::exception.

다른 사람들은 std::exception문자 메시지를 전달할 수 없다는 문제 가 있다고 대답 했지만 일반적으로 던지는 시점에서 사용자 메시지를 형식화하는 것은 좋지 않습니다. 대신 예외 개체를 사용하여 모든 관련 정보를 catch 사이트로 전송 한 다음 사용자 친화적 인 메시지 형식을 지정할 수 있습니다.

상속을 원하는 이유 std::exception는 그 클래스에 따라 잡힌 예외를 던질 수 있기 때문입니다.

class myException : public std::exception { ... };
try {
    ...
    throw myException();
}
catch (std::exception &theException) {
    ...
}

상속에 대해 알아야 할 한 가지 문제는 객체 슬라이싱입니다. throw e;throw-expression 을 작성할 때 예외 객체라고하는 임시 객체를 초기화합니다.이 객체의 유형은 피연산자의 정적 유형에서 최상위 수준 cv 한정자를 제거하여 결정됩니다 throw. 그것은 당신이 기대하는 것이 아닐 수 있습니다. 여기에서 찾을 수있는 문제의 예 .

상속에 대한 주장이 아니라 '필수'정보 일뿐입니다.

차이점 : std :: runtime_error 대 std :: exception ()

상속 여부는 귀하 에게 달려 있습니다. 표준 std::exception및 그 하위 규격은 하나 명의 가능한 예외 계층 구조 (분할에 제안 logic_errorsubhierarchy 및 runtime_errorsubhierarchy) 및 하나의 가능한 예외 객체 인터페이스. 당신이 그것을 좋아한다면-그것을 사용하십시오. 어떤 이유로 다른 것이 필요한 경우 고유 한 예외 프레임 워크를 정의하십시오.

언어가 이미 std :: exception을 던 졌기 때문에 괜찮은 오류보고를 제공하기 위해 어쨌든 그것을 잡아야합니다. 예상치 못한 모든 예외에 대해 동일한 캐치를 사용할 수도 있습니다. 또한 예외를 발생시키는 거의 모든 라이브러리는 std :: exception에서 파생됩니다.

즉,

catch (...) {cout << "Unknown exception"; }

또는

catch (const std::exception &e) { cout << "unexpected exception " << e.what();}

그리고 두 번째 옵션은 확실히 더 좋습니다.

가능한 모든 예외가에서 파생되는 std::exception경우 catch 블록은 catch(std::exception & e)모든 것을 간단하게 캡처 할 수 있습니다 .

예외를 캡처 한 후에는 해당 what메서드를 사용 하여 자세한 정보를 얻을 수 있습니다. C ++는 덕 타이핑을 지원하지 않으므로 what메서드가 있는 다른 클래스에서이를 사용하려면 다른 catch와 다른 코드가 필요합니다.

표준 예외 유형에서 파생할지 여부가 첫 번째 질문입니다. 이렇게하면 모든 표준 라이브러리 예외 및 사용자 고유에 대해 단일 예외 처리기를 사용할 수 있지만 이러한 모든 예외 처리기를 권장합니다. 문제는 처리 방법을 알고있는 예외 만 포착해야한다는 것입니다. 예를 들어 main ()에서 모든 std :: exceptions를 잡는 것은 종료하기 전에 what () 문자열이 최후의 수단으로 기록 될 경우 좋은 일입니다. 그러나 다른 곳에서는 좋은 생각이 아닐 것입니다.

표준 예외 유형에서 파생할지 여부를 결정한 후에는 어느 것이 기본이되어야하는지에 대한 질문이 있습니다. 응용 프로그램에 i18n이 필요하지 않은 경우 호출 사이트에서 메시지 서식을 지정하는 것이 정보를 저장하고 호출 사이트에서 메시지를 생성하는 것만 큼 좋다고 생각할 수 있습니다. 문제는 형식화 된 메시지가 필요하지 않을 수 있다는 것입니다. 지연 메시지 생성 체계를 사용하는 것이 더 좋습니다. 아마도 미리 할당 된 메모리를 사용하는 것입니다. 그런 다음 메시지가 필요한 경우 액세스시 생성되고 예외 개체에 캐시 될 수 있습니다. 따라서 메시지가 throw 될 때 생성되면 std :: runtime_error와 같은 std :: exception 파생이 기본 클래스로 필요합니다. 메시지가 느리게 생성되는 경우 std :: exception이 적절한 기준입니다.

하위 클래스 예외가 발생하는 또 다른 이유는 캡슐화 된 대규모 시스템에서 작업 할 때 더 나은 설계 측면입니다. 유효성 검사 메시지, 사용자 쿼리, 치명적인 컨트롤러 오류 등과 같은 것에 재사용 할 수 있습니다. 메시지와 같은 모든 유효성 검사를 다시 작성하거나 다시 연결하는 대신 기본 소스 파일에서 간단히 "catch"할 수 있지만 전체 클래스 집합에서 오류가 발생합니다.

예를 들어 치명적인 예외는 프로그램을 종료하고 유효성 검사 오류는 스택을 지우고 사용자 쿼리는 최종 사용자에게 질문을합니다.

이렇게하면 동일한 클래스를 다른 인터페이스에서 재사용 할 수도 있습니다. 예를 들어 Windows 응용 프로그램은 메시지 상자를 사용할 수 있으며 웹 서비스는 html을 표시하고보고 시스템은이를 기록하는 식입니다.

이 질문은 다소 오래되었고 이미 많은 답변을 받았지만 예외에 대한 토론에서 계속해서 이것을 놓치고 있기 때문에 C ++ 11에서 적절한 예외 처리를 수행하는 방법에 대한 메모를 추가하고 싶습니다.

사용 std::nested_exception및std::throw_with_nested

StackOverflow here 및 here 에 설명 되어 있으며, 중첩 된 예외를 다시 발생시키는 적절한 예외 처리기를 작성하여 디버거 나 번거로운 로깅없이 코드 내부의 예외에 대한 역 추적을 얻는 방법에 대해 설명합니다 .

파생 된 예외 클래스를 사용하여이를 수행 할 수 있으므로 이러한 역 추적에 많은 정보를 추가 할 수 있습니다! GitHub 에서 내 MWE를 살펴볼 수도 있습니다. 역 추적은 다음과 같습니다.

Library API: Exception caught in function 'api_function'
Backtrace:
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt"

std::runtime_error예외가 발생할 때 많은 정보를 얻기 위해 하위 클래스 를 만들 필요조차 없습니다 .

서브 클래 싱에서 볼 수있는 유일한 이점 std::runtime_error은 예외 처리기가 사용자 정의 예외를 포착하고 특별한 작업을 수행 할 수 있다는 것입니다. 예를 들면 :

try
{
  // something that may throw
}
catch( const MyException & ex )
{
  // do something specialized with the
  // additional info inside MyException
}
catch( const std::exception & ex )
{
  std::cerr << ex.what() << std::endl;
}
catch( ... )
{
  std::cerr << "unknown exception!" << std::endl;
}