[exception] 예외 처리가 나쁜 이유는 무엇입니까?

예외는 throw되는 예외가 불변성을 깨고 객체를 일관성없는 상태로 남겨 두는 코드를 작성하는 것을 정말 쉽게 만듭니다. 그들은 본질적으로 당신이 만드는 대부분의 진술이 잠재적으로 던질 수 있다는 것을 기억하고 올바르게 처리하도록 강요합니다. 그렇게하는 것은 까다 롭고 직관적이지 않을 수 있습니다.

다음과 같은 것을 간단한 예로 고려하십시오.

class Frobber
{
    int m_NumberOfFrobs;
    FrobManager m_FrobManager;

public:
    void Frob()
    {
        m_NumberOfFrobs++;

        m_FrobManager.HandleFrob(new FrobObject());
    }
};

가정 FrobManager것이다 오른쪽이 외모 확인을? 아니면 아닐 수도 있습니다 … 그렇다면 또는 예외가 발생하는 경우를 상상해보십시오 . 이 예에서 증분은 롤백되지 않습니다. 따라서이 인스턴스를 사용하는 사람 은 개체가 손상되었을 수 있습니다.deleteFrobObjectFrobManager::HandleFrob()operator newm_NumberOfFrobsFrobber

이 예제는 어리석은 것처럼 보일 수 있지만 (좋아요, 하나를 구성하기 위해 약간의 노력을 기울여야했습니다. :-)),하지만 핵심은 프로그래머가 예외를 계속 생각하지 않고 모든 상태 순열이 롤링되는지 확인하는 것입니다. 던질 때마다 이런 식으로 문제가 생깁니다.

예를 들어 뮤텍스를 생각하는 것처럼 생각할 수 있습니다. 중요한 섹션 내에서 데이터 구조가 손상되지 않았는지, 다른 스레드가 중간 값을 볼 수 없는지 확인하기 위해 여러 명령문에 의존합니다. 이러한 진술 중 하나가 무작위로 실행되지 않으면 고통의 세계에 빠집니다. 이제 잠금과 동시성을 제거하고 각 방법에 대해 그렇게 생각하십시오. 원한다면 각 방법을 객체 상태에 대한 순열 트랜잭션으로 생각하십시오. 메서드 호출을 시작할 때 개체는 깨끗한 상태 여야하고 마지막에는 깨끗한 상태 여야합니다. 그 사이에 변수 foo는 다음과 일치하지 않을 수 있습니다.bar, 그러나 귀하의 코드는 결국 그것을 수정할 것입니다. 예외의 의미는 귀하의 진술 중 하나가 언제든지 귀하를 방해 할 수 있다는 것입니다. 각 개별 메서드에서 문제가 발생하면 문제가 발생하면 롤백하거나 작업을 정렬하여 throw가 개체 상태에 영향을주지 않도록해야합니다. 잘못 이해하면 (그리고 이런 종류의 실수를하기 쉽습니다) 호출자는 결국 중간 값을 보게됩니다.

C ++ 프로그래머가이 문제에 대한 궁극적 인 해결책으로 언급하기를 좋아하는 RAII와 같은 메서드는이를 방지하기 위해 먼 길을갑니다. 그러나 그것들은 은총 알이 아닙니다. 던질 때 리소스를 해제 할 수는 있지만 객체 상태의 손상과 호출자가 중간 값을 보는 것에 대해 생각할 필요가 없습니다. 따라서 많은 사람들에게 코딩 스타일의 명목상 예외 는 없다고 말하는 것이 더 쉽습니다 . 작성하는 코드의 종류를 제한하면 이러한 버그를 도입하기가 더 어렵습니다. 그렇지 않으면 실수하기가 매우 쉽습니다.

C ++의 예외 안전 코딩에 대해 전체 책이 작성되었습니다. 많은 전문가들이 잘못 알고 있습니다. 정말 그렇게 복잡하고 뉘앙스가 너무 많다면 해당 기능을 무시해야한다는 좋은 신호일 수 있습니다. 🙂