- MoreEffectiveC++/Exception . . . . 6 matches
pa에 해당하는 processAdoption()은 오류시에 exception을 던진다. 하지만, exception시에 해당 코드가 멈춘다면 "delete pa;"가 수행되지 않아서 결국 자원이 새는 효과가 있겠지 그렇다면 다음과 같이 일단 예외 처리를 한다. 물론 해당 함수에서 propagate해주어 함수 자체에서도 예외를 발생 시킨다.
이렇게 해도 여전히 문제는 남는다. 무엇이냐 하면, 만약 BookEntry의 생성자중에서 AudioClip 객체 생성중에 예외를 propagate하면 바로 위 코드중 pb 포인터에 null을 반환해 버린다. 반납된 이렇게 되면 이미 정상적으로 생성된 theImage를 지우지 못하는 사태가 발생해 버리는 것이다.
예외처리시에 다른 객체의 사본이 전달 된다는 점은 예외가 계속 전달(퍼져나갈때,propagate)에도 한가지의 고려사항이 발생한다. 다음의 두가지의 catch 블럭은 차이점이 있다. 하지만 외견상 같은 역할을 한다.
throw w; // 해당 객체를 다시 복사해서 그 사본을 propagate한다.
만약 위와 같이 하고 bad_exception(표준 라이브러리 상의 exception의 기본 예외 클래스)를 당신의 모든 예외 명세에 포함시키면 당신은 결코 당신ㄴ의 프로그램이 불시에 멈추어 버리는것에 대한 걱정을 할 요는 없을 것이다. 거기다가 규정에 맞지않는 예외들도 bad_exception으로 교체되고 예외는 기본 예외 대신에 다시 던저 퍼진다.(propagate)
물론 저것은 이론이다. 실질적으로 예외 지원 밴더들은 당신이 예외 작성을 위한 코드의 첨가를 당신이 예외를 지원하느냐 마느냐에 따라 조정할수 있도록 만들어 놓았다.(작성자주:즉 예외 관련 처리의 on, off가 가능하다.) 만약 당신이 당신의 프로그램의 어떠한 영역과, 연계되는 모든 라이브러리에서 try, throw, catch를 빼고 예외 지원 사항을 빼고 당신 스스로 속도, 크기 같은 예외처리시 발생하는 단점을 제거할수 있을 것이다. 시감이 지나 감에 따라 라이브러리에 차용되는 예외의 처리는 점점 늘어나게 되고, 예외를 제거하는 프로그래밍은 갈수록 내구성이 약해 질것이다. 하지만, 예외처리를 배제한 컴파일을 지원하는 현재의 C++ 소프트웨어 개발상의 상태는 확실히 예외처리 보다 성능에서 우위를 점한다. 그리고 그것은 또한 예외 전달(propagate) 처리와, 예외를 생각하지 않은 라이브러리들의 사용에 무리없는 선택이 될것이다.
- EffectiveC++ . . . . 1 match
throw; // propagate
- SmalltalkBestPracticePatterns/DispatchedInterpretation . . . . 1 match
Back in the days when data was separated from computation, and seldom the twain should meet, encoding decisions were critical. Any encoding decision you made was propagated to many different parts of the computation. If you got the encoding wrong, the cost of change was enormous. The longer it took to find the mistake, the more ridiculous the bill.
Found 3 matching pages out of 7540 total pages (5000 pages are searched)
You can also click here to search title.
