적어도 하나의 신뢰할 수있는 소스 (내가 취한 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) {
...
}