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

첫 번째 '심각한'C ++ 라이브러리를 디자인하는 동안 나 자신에게 묻습니다.

예외를 파생시키는 것이 좋은 스타일입니까, std::exception자손입니까?!

읽은 후에도

• 예외 클래스 설계
• 내 라이브러리에 구현할 '좋은 수'의 예외는 무엇입니까?

아직 확실하지 않습니다. 일반적인 관행 (아마도 좋지는 않지만) 관행 외에도 라이브러리 사용자 std::exception는 라이브러리 구현에서 표준 라이브러리 함수가 실패한 경우에만 라이브러리 함수가 throw 되고 이에 대해 아무것도 할 수 없다고 가정합니다. 그러나 여전히 응용 프로그램 코드를 작성할 때 매우 편리하며 IMHO는을 던지는 것이 std::runtime_error좋습니다. 또한 내 사용자는 what()또는 코드 와 같이 정의 된 최소 인터페이스에 의존 할 수도 있습니다 .

예를 들어, 내 사용자는 잘못된 인수를 제공합니다.를 던지는 것보다 더 편리한 std::invalid_argument것은 무엇입니까? 그래서 std :: exception의 일반적인 사용법과 결합하여 다른 코드에서 볼 수 있습니다 std::exception.

생각?

모든 예외는에서 상속되어야합니다 std::exception.

예를 들어,을 호출해야하고 ComplexOperationThatCouldFailABunchOfWays()예외를 처리하려고 한다고 가정하십시오 . 모든 것이에서 상속되면 std::exception쉽습니다. 단일 catch블록 만 필요하며 what()세부 정보를 얻기위한 표준 인터페이스 ( )가 있습니다.

try {
    ComplexOperationThatCouldFailABunchOfWays();
} catch (std::exception& e) {
    cerr << e.what() << endl;
}

예외가에서 상속되지 않으면 std::exception훨씬 더 나빠집니다.

try {
    ComplexOperationThatCouldFailABunchOfWays();
} catch (std::exception& e) {
    cerr << e.what() << endl;
} catch (Exception& e) {
    cerr << e.Message << endl;
} catch (framework_exception& e) {
    cerr << e.Details() << endl;
}

던질 것인지 runtime_error또는 던질 invalid_argument자신의 std::exception서브 클래스를 만들지 에 관한 것 : 내 경험상 다른 오류와 다르게 특정 유형의 오류를 처리해야 할 때마다 (즉, 별도의 catch블록이 필요할 때마다) 새로운 서브 클래스를 도입하는 것이 좋습니다 .

• 생각할 수있는 모든 유형의 오류에 대해 새로운 예외 서브 클래스를 도입하면 개별적으로 처리 할 필요가 없더라도 많은 클래스 확산이 추가됩니다.
• 기존 서브 클래스를 재사용하여 특정 무언가를 의미하는 경우 (즉, 여기 에 runtime_error던져진 것이 일반 런타임 오류와 다른 것을 의미하는 경우) 기존 서브 클래스의 다른 용도와 충돌 할 위험이 있습니다.
• 내가하면 하지 않는 구체적으로 오류를 처리해야하고, 내가 던지고있어 그 오류가 정확히 기존의 표준 라이브러리의 오류 중 하나 (예 : 일치하는 경우 invalid_argument), 그때는 기존의 클래스를 다시 사용합니다. 이 경우 새 클래스를 추가해도 큰 이점이 없습니다. (C ++ 핵심 지침은 여기에 동의하지 않습니다. 항상 자신의 클래스를 사용하는 것이 좋습니다.)

C ++ 핵심 가이드 라인은 자세한 설명과 예제가 있습니다.

라이브러리 사용자는 라이브러리 구현에서 표준 라이브러리 함수가 실패했을 때만 라이브러리 함수가 std :: exceptions를 throw하고 아무것도 할 수 없다고 가정합니다.

그것은 잘못된 가정입니다.

"일반적인"사용을 위해 표준 예외 유형이 제공됩니다. 표준 라이브러리 에서만 사용 하도록 설계되지 않았습니다 .

예, 모든 것을 궁극적으로에서 상속 받으십시오 std::exception. 종종 std::runtime_error또는 에서 상속을받는 경우가 있습니다 std::logic_error. 구현하는 예외 클래스에 적합한 것이 무엇이든간에.

이것은 물론 주관적이다. 몇몇 인기있는 라이브러리는 표준 예외 유형을 완전히 무시하고 아마도 표준 라이브러리에서 라이브러리를 분리 할 것이다. 개인적으로 나는 이것이 매우 이기적이라고 생각합니다! 예외를 잡기가 훨씬 어려워집니다.

개인적으로 말하면, 나는 종종 그냥 던져서 std::runtime_error처리합니다. 그러나 그것은 예외 클래스를 만드는 것이 얼마나 세분화되는지에 대한 토론으로 들어가고 있습니다.