예외를 무시하지 말라 매우 뻔한 얘기같지만 생각보다 사람들이 자주 어기는 부분이다. API 설계자가 메서드 선언에 예외를 명시하는 이유는 그 메서드를 사용할 때 적절한 조치를 취해달라고 어필하기 위함이다. 예외를 무시하는 것은 아주 쉽다. try로 감싼 뒤 catch 블록에서 아무 일도 하지 않으면 된다. catch 블록은 문제 상황에 대처하기...

가능한 한 실패 원자적으로 만들라 실패 원자적이란? 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지하는 특성. 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있는 상태면 좋을 것이다. 만약 예외가 검사 예외인 경우에는 호출자가 오류 상태를 복구할 수 있으니 더더욱 좋을 것이다...

예외의 상세 메시지에 실패 관련 정보를 담으라 예외를 잡지 못해 프로그램이 실패하면 그 예외의 Stack Trace 정보를 자동으로 출력한다. 이 스택 추적 정보는 예외 객체의 toString 메서드를 호출해 얻는 문자열로, 보통은 예외의 클래스 이름 뒤에 상세 메시지가 붙는 형태이다. 이러한 정보는 프로그래머가 얻을 수 있는 유일한 정보인 경우...

메서드가 던지는 모든 예외를 문서화하라 메서드가 던지는 예외는 해당 메서드를 올바르게 사용하는 데 아주 중요한 정보이다. 따라서 각 메서드가 던지는 예외 하나하나를 문서화하는 데 충분한 시간을 들여야 한다. 검사 예외 문서화 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 JavaDoc의 @throws 태그를 사용해 정확히 문서...

추상화 수준에 맞는 예외를 던지라 수행하려는 일과 관련 없어 보이는 예외가 나타나면 당황스럽다. 이는 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파하는 경우 종종 발생하는 일이다. 이러한 일은 프로그래머를 당황시키는 정도에 그치지 않고, 내부 구현 방식을 드러낸다는 치명적인 문제를 가지고 있다. 상위 레벨의 API를 오염시킨다. 만약 다음...

표준 예외를 사용하라 숙련된 프로그래머는 그렇지 못한 프로그래머보다 코드 재사용 빈도가 높다. 예외도 마찬가지다. 재사용하는 것이 좋다. 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다. 표준 예외를 재사용하면 얻는 이점은 아래와 같다. 다른 사람이 API를 익히고 사용하기 쉬워진다. 많은 프로그...

필요 없는 검사 예외 사용은 피하라 이전 아이템인 아이템 70에서도 살짝 언급한 부분이다. 물론 검사 예외를 잘 활용하면 발생한 예외를 프로그래머가 처리하여 안전성을 높이고, 프로그램의 질을 높일 수 있다. 하지만 검사 예외를 과하게 사용하면 사용하기 불편한 API가 된다. 검사 예외를 사용하게 되면, catch 블록을 두어 그 예외를 붙잡아 ...

복구할 수 있는 상황에서는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 Java에서는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 3가지를 제공한다. 검사 예외 (Checked Exception) 반드시 처리해야 하는 예외로 컴파일 단계에서 확인이 가능하다. ...

예외는 진짜 예외 상황에만 사용하라 예외를 제대로 활용하면 프로그램의 가독성, 신뢰성, 유지보수성이 높아진다. 하지만 잘못 사용하는 경우 역효과가 난다. 예외를 잘못 사용하는 사례들을 보고 예외를 어떻게 사용해야 하는지 보자. 코드가 직관적이지 않고 성능 문제가 발생한다. try { int idx = 0; while (true) { ra...

일반적으로 통용되는 명명규칙을 따르라 자바는 명명 규칙이 잘 정립되어 있다. 자바의 명명 규칙은 크게 철자와 문법 두 범주로 나뉜다. 철자 규칙 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름 문법 규칙 자바 문법에 대한 부분 (반복문, 예외 등등) 특...