해당 포스팅은 톰 롱의 Good Code, Bad Code (P.108~119)를 읽고 정리한 글입니다.복구할 수 없는 오류의 전달현실적으로 복구할 가능성이 없는 오류가 발생하면 신속하게 실패하고, 요란하게 실패하는 것이 최상의 방법이다. 이를 달성하기 위한 방법으로비검사 예외를 발생패닉 (패닉을 지원하는 언어를 사용하는 경우)체크나 어서션 사용이 경우 프로그램이 종료되므로 개발자에게 강력하게 경고하고, 스택 트레이스와 줄 번호를 제공하여 오류 발생 위치를 명확하게 알린다. 또한, 복구할 수 없는 오류일 경우 호출한 측에서 오류를 단순히 전달하기 때문에, 암시적 전달 방식으로 별도의 처리 코드 작성이 필요 없도록 하는 게 효율적이다.호출하는 쪽에서 복구하기를 원할 수도 있는 오류의 전달개발자들 사이에서 ..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.98~107)를 읽고 정리한 글입니다.  명시적 방법널값이 가능한 반환 유형널 안정성을 지원하는 경우 널값이 반환될 수 있다는 것을 호출하는 쪽에서 강제적으로 인지하고, 그에 따라 처리할 수밖에 없다. 따라서 널값이 가능한 반환 유형을 사용하는 것은 오류를 전달하기 위한 명시적인 방법이다. 만약 널 안정성을 지원하지 않는 언어를 사용할 경우 옵셔널 반환 유형을 사용하는 것이 좋다.더보기널 안정성 (Null Safety)프로그래밍에서 NPE(NullPointException)를 방지하기 위한 기능 의미널 안정성을 지원하는 언어는 이를 예방하기 위해컴파일 타임에서 널 값 사용 가능성을 체크Null이 될 수 있는 변수와 그렇지 않은 경우를 구분하..

해당 포스팅은 톰롱의 Good Code, Bad Code(P. 94~98)를 읽고 정리한 글입니다. 예외예외는 코드에서 오류나 예외적인 상황이 발생한 경우 이를 전달하기 위한 방법으로 고안되었다. 자바는 검사 예외(Checked Exception)와 비검사 예외(Unchecked Exception)가 있다. 예외가 발생할 때 콜 스택을 거슬러 올라가는데 예외를 처리하는 코드를 만나거나, 더 이상 올라갈 콜 스택이 없을 때까지 그렇게 한다. 더 이상 올라갈 콜 스택이 없는 경우에는 오류 메세지를 출력하고 프로그램이 종료된다.명시적인 방법 : 검사 예외 (Checked Exception)컴파일러는 Checked Exception에 대해 호출하는 측에서 반드시 예외를 인지하도록 강제한다. 따라서 호출하는 측에..

해당 포스팅은 톰롱의 Good Code, Bad Code(P. 88~94)를 읽고 정리한 글입니다. 오류를 숨기지 않음오류를 숨기는 것은 복구할 수 있는 오류와 복구할 수 없는 오류 모드에 문제를 일으킨다.호출하는 쪽에서 복구하고자 할 수도 있는 오류를 숨기면, 호출하는 쪽에서 오류로부터 복구할 수 있는 기회를 없애는 것이다. 개발팀이 그 오류에 대해 전혀 알지 못할 수도 있다는 것을 의미한다.실제로 코드는 동작하지 않기 때문에 잘못된 정보를 출력하거나 일부 데이터를 시키거나 작동을 멈출 수 있다. 오류를 숨길 수 있는 방법이러한 기술 중 일부는 다른 상황에서 유용하지만 오류 처리에 있어서는 일반적으로 모두 바람직하지 않다.기본값 / Null 객체 반환아무것도 하지 않음오류 신호 보내지 않기오류를 적극적..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.84~87)를 읽고 정리한 글입니다. 오류가 발생할 때, 우리는 두 가지 옵션이 있다.실패, 더 높은 코드 계층이 오류 처리 또는 전체 프로그램 작동 멈춤오류 처리 후 계속 진행2번 선택지가 1번보다 견고한 코드라고 볼 수 있지만, 더 큰 문제를 야기할 수 있다. 해당 파트에서 정리할 내용은 아래 2가지이다.견고성보다 실패가 많은 경우에 있어 최선인 이유적절한 수준의 로직에서 견고성도 가질 수 있는 방법 원칙 1. 신속하게 실패하라가능한 한 문제의 실제 발생 지점으로부터 가까운 곳에서 오류를 나타내야 한다. 이렇게 된다면 2가지 이점을 가지게 되는데복구할 수 있는 오류의 경우 호출하는 쪽에서 오류로부터 훌륭하고 안전하게 복구할 수 있는 기회..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.79~84)를 일고 정리한 글입니다. 코드는 불완전한 환경에서 실행되므로 오류는 필연적이며, 이를 적절히 처리하는 것이 신뢰성 높은 소프트웨어 개발의 핵심이다. 오류에 대해 생각할 때 소프트웨어가 작동을 계속할 수 있는 오류와 작동을 계속할 합리적인 방법이 없는 오류로 구분하는 것이 유용할 때가 많다.복구 가능성복구 가능한 오류많은 소프트웨어 오류는 치명적이지 않으며, 오류가 발생하더라도 사용자는 알아채지 못하도록 적절하게 처리한다면 작동을 계속할 수 있는 합리적인 방법이 있다.복구 가능한 오류의 예사용자의 잘못된 입력네트워크 오류중요하지 않은 작업 오류일반적으로 시스템 외부의 무언가에 의해 야기되는 오류에 대해서는 대부분 시스템 전체가 표..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.73~75)를 읽고 정리한 글입니다.  체크 및 어서션세부 조항을 최소화하는 것이 중요하며, 가장 신뢰할 수 있는 방법은 컴파일러를 통해 계약을 확인하는 것이다. 그러나 이것이 불가능할 경우, 체크나 어서션을 활용하여 런타임에 계약을 검증할 수 있다. 이를 통해 코드 계약 조건을 확인하고, 준수를 강제할 수 있다. 체크체크는 코드 계약의 준수 여부를 확인하는 추가적인 로직이며, 계약이 지켜지지 않으면 오류를 발생시켜 실패를 유발한다. 이러한 실패는 명확하게 드러나므로, 문제를 놓치는 것을 방지하는 역할을 한다. 체크는 시행 중인 계약 조건에 따라 다음과 같은 범주로 구분된다.전제 조건 검사 예를 들어 파라미터가 올바르거나, 초기화가 수행되었..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.64~73)를 읽고 정리한 글입니다. 계약에 의한 프로그래밍 또는 계약에 의한 디자인이라는 철학에서는 서로 다른 코드 간의 상호작용을 마치 계약처럼 생각한다. 코드 계약에 대한 용어를 다음과 같은 세 가지 범주로 나누면 유용하다.선결 조건 precondition코드를 호출하기 전에 사실이어야 하는 것예를 들어, 시스템이 어떤 상태에 있어야 하는지, 어떤 입력을 공급해야 하는지와 같은 사항사후 조건 postcondition코드가 호출된 후에 사실이어야 하는 것시스템이 새로운 상태에 놓인다든지 반환되는 값과 같은 사항불변 사항 invariant코드가 호출되기 전과 후에 시스템 상태를 비교해서 변경되지 않아야 하는 사항입력 매개변수가 있는 함수를..