본문 바로가기

CPPCS

 (85)
항목 75 : 예외 명세표는 만들 필요가 없다. ( Avoid exception specifications. ) 관련 링크로 대신 한다. http://ikpil.com/807
항목 73 : 예외를 발생시킬 때에는 값으로 하고, 잡아낼 때에는 참조로 하라. ( Throw by value, catch by reference. ) { 개요 이번 포스팅은 예외를 발생시키는 좋은 예와 잡아낼 때 좋은 예를 정리하는 것에 그 목적을 두고 있다. 본문 예외는 어떻게 발생 시킬 수 있는가? 예외는 try 구문 내에서 throw a; 형태로 발생 시킬 수 있다. 이 때 a 는 어떠한 타입도 가능하다. 즉, 포인터,기본형, 객체형이 가능하다는 뜻이다. 이렇게 발생된 예외는 어떻게 잡을 수 있는가? catch 구문을 통해서 잡을 수 있다. 다음과 같이 catch( int a ) 형태 이다. 위의 a가 int 형이라면 잡을 수 있다. 만약 int 형이 아니라면, 잡을 수 없고 try catch 구문 밖으로 예외는 자동으로 나가게 된다. 예) #include int main( void ) { try { throw "abcdefg\n"; std::c..
항목 72 : 오류 보고에는 예외를 활용하라. ( Prefer to use exceptions to report errors. ) { 개요 이번 포스팅은 예러를 보고 할 때, 예외:Exception와 에러코드:Error Code 중 예외가 어떻게 더 좋은지에 대해서 정리한 것이다. 본문 에러를 보고 한다는게 무슨 의미인가? 에러를 보고 한다는 것은 어떤 에러가 났는지 프로그래머에게 알리는 의미를 갖는다. 에러를 보고하는데 어떤 방법이 있는가? 대표적으로 에러코드(리턴코드)를 이용하여 함수의 리턴값으로 보고하는 형태와 예외(Exception)를 던지는 형태가 있다. 대표적인 이 방법중 무엇이 더 좋은가? 예외를 던지는 형태가 더 좋다. 왜 더 좋은가? 1. 예외는 무시될 수 없다. 리턴코드는 리턴에 대해서 처리 하지 않으면, 그냥 무시하고 넘어간다. 결국 이 것을 처리하기 위해선 항상 리턴코드를 제크해야 하는 번거러움이 있다. 하지만..
항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라. ( Design and write error-safe code. ) 항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라 { 라고 .. 책에는 적혀 있다. 번역하다가 Exception 이 오류라고 된거 같다. 본 내용은 예외로부터 안전한 코드를 디자인하고 작성하는 것을 이야기 하는 것이다. 개요 이 포스팅은 발생된 예외:Exception으로 부터 프로그램을 보호해야 하는 이유와 어떤 보호방법들이 있는지, 어떻게 보호해야 하는지에 대해서 정리해 둔 것이다. 본문 발생된 예외로 부터 왜 프로그램을 보호해야 하는가? 보호를 할지 말지는 프로그래머가 정하는 일이다. 만약 "나는 보호하지 않겠어" 라고 한다면, 이 포스팅을 읽지 않아도 된다. 예외가 발생 했을 경우, 그 예외는 자신의 지역에서 처리 할 수 있는 곳이 있는지 살펴보고, 있다면 그곳에 머물러 처리가 될 테니지만..
항목 70 : 어디까지가 오류인지 명확히 해두자. ( Distinguish between errors and non-errors. ) { 개요 에러란 무엇이고, 어디서 발생하는지 이해함으로써, 디버깅 능력 향상을 위해 정리하였습니다. 본문 에러란 무엇인가? 작업이 의도하지 않은 방향으로 가는 것, 이것을 에러라 한다. 이러한 작업의 최소한 단위는 함수인데. 함수가 의도하지 않는 방향으로 간다면, 에러가 발생했다고 봐야 한다. 어디까지 의도하지 않는 방향으로 가야 에러인가? 함수가 자신이 맡은 책임을 다하지 못하고, 다름 함수에게까지 도달한다면, 에러라고 봐야한다. 그렇다면 함수에 어떤 에러가 있을까? 1. 필요한 전제조건이 만족하지 못하고 함수를 호출하는 오류 2. 함수의 결과값이 정상적이지 않는 오류 3. 불변 의무를 가진 변수를 건들거나 복구하지 않는 오류 이러한 오류들이 존재한다. 말로만 설명하지 말고 코드을 보여 줄수 있는가? ..
항목 69 : 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라. ( Establish a rational error handling policy, and follow it strictly. ) { 이 항목은 몸에 와 닿지 않는다. 아무래도 이런 개발 프로세스를 사용해 본적이 한번도 없기 때문이다. 회사에서 로그를 남기는 것으로 처리 하는게 아마도 이런 개발 프로세스 인것 같다. 이것이 왜 중요한가? 보통은 안써도 크게 무리 없지만 프로젝트의 규모가 커지거나, 프로젝트에 붙는 사람들의 숫자가 많아 질 수록 프로젝트의 관리도 더불어 힘들어 진다. 그러면서 디버깅은 점점 힘들어 진다. 만약 오류의 처리 방식, 보고 방식, 표현 방식이 정해져 있다면 좀 더 편할 것이다. 책에서는 모라고 하는가? 개발 초기에 먼저 정하고 개발하라고 한다. 어떻게 정하는가? 오류를 우선 식별하는 기준을 정한다. 예를 들어 babo_num > 30 이면 오류이다. 라고 정한다. 그리고 오류의 수준을 정한다. babo_nu..
항목 68 : 내부적인 가정과 규칙을 확실하게 명시하라. ( Assert liberally to document internal assumptions and invariants. ) { 즉, 자신 또는 우리가 만들어 놓은 프로그램이 올바르게 작동하기 위해서 내부적인 가정과 규칙을 확실하게 명시해 둘 필요가 있다는 이야기이다. 여기서 말하는 규칙과 가정은 무엇을 말하는가? 오류의 보고와 오류의 표현, 오류의 범위을 뜻한다. 이것을 왜 확실하게 명시해야 하는가? 나 혼자 작업을 한다면, 일관성 있게 유지해야 함은 나 자신에게 무척 도움이 된다.(나중에 봐도 알 수 있으니까) 마찬가지로 팀에서도 명시된 룰을 적용하면, 모두가 좋다. 대표적으로 assert를 사용하는 사람과 사용하지 않는 사람이 같이 작업을 했다고 했을 때, 릴리즈 모드와 디버깅 모드에서 다른 결과를 볼 수 있는 것을 예로 들 수 있다. 그러므로 확실하게 명시하는 편이 좋다. 부수적인 이야기 assert 이야기가 나와으니 ..
항목 100 : 배열을 다형적으로 다루어서는 안된다. ( Don’t treat arrays polymorphically. ) { 왜냐하면 배열은 연속적인 메모리 배열이기 때문에, 다른 형으로 변환 되었을 때 이동되는 단위가 달라지기 때문이다. 이런 것들이 필요할 경우, 한번 포장해서 인터페이스를 제공해서 사용해야 한다고 책에 나와 있다. .. 당연하잖아! }