오딩이

꼭 필요한 곳에만 사용한다면 검사 예외는 프로그램의 안전성을 높여주지만, 남용하면 쓰기 고통스러운 API를 낳는다. 📢 검사 예외 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게끔 해준다. 물론, 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야만 한다. API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이 정도 부담은 감안할 수 있다. 하지만 둘 다 해당하지 않는다면 비검사 예외를 사용하는 것이..

throwable은 사용하지 말자. 자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러를 제공한다. 언제나 100% 명확한 건 아니지만 따르는 지침들이 있다. 📢 검사예외 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 즉, API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한다. 비검사 throwable은 두 가지로, 바로 런타임 예외와 에러다. 둘 다 동작 측면에서는 다르지 않다. 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다. 즉, 프로그램에서 비검사 예외나 에러를 던졌다는 ..

예외는 예외 상황에서 쓸 의도로 설계되었다. 예외는 오직 예외 상황에서만 써야 한다. 🙄 예외는 오직 예외 상황에서만 써야 한다. 예외는 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다. 예외를 사용해서 성능이 좋아지더라도 자바 플랫폼이 꾸준히 개선되고 있으니 최적화로 얻은 상대적인 성능 우위가 오래가지 않을 수 있다. 반면 과하게 영리한 기법에 숨겨진 미묘한 버그의 폐해와 어려워진 유지보수 문제는 계속 이어질 것이다. 😊 잘 설계된 API -> 예외를 사용할 일이 X 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다. 특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드도 함께 제공해야 한다. ( Iterator 인터..

표준 명명 규칙을 체화하여 자연스럽게 배어 나오도록 하자 자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 크게 철자와 문법, 두 범주로 나뉜다. 철자 규칙이나 문법 규칙을 어기면 다른 프로그래머들이 그 코드를 읽기 번거로울 뿐 아니라 다른 뜻으로 오해할 수도 있고 그로 인해 오류까지 발생할 수 있다. 🎈 철자 규칙 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다. 철자 규칙을 어긴 API는 사용하기 어렵고, 유지보수하기 어렵다. 패키지와 모듈 각 요소를 점(.)으로 구분하여 계층적으로 짓는다. 요소들은 모두 소문자 알파벳 혹은 숫자로 이뤄진다. 조직 바깥에서도 사용될 패키지라면 인터넷 도메인 이름을 역순으로 사용한다. ex) edu.cmu, com.google, or..