오딩이

예외가 발생해도 객체가 여전히 정상적으로 사용할 수 있는 상태라면 검사 예외를 던진 경우, 호출자가 오류 상태를 복구할 수 있다. 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 이러한 특성을 실패 원자적(failure-atomic)이라고 하는데, 실패 원자적 특성을 활용하면 작업 도중 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있는 상태이고, 검사 예외를 던진 경우에 호출자가 오류 상태를 복구할 수 있으니 매우 유용하다. 💡 메서드를 실패 원자적으로 만드는 다양한 방법 첫 번째, 불변 객체로 설계한다. (가장 간단한 방법) 불변 객체는 태생적으로 실패 원자적이다. 메서드가 실패하면 새로운 객체가 만들어지지 않을 수 있으나 기존 객체가 불안정한 상태에 빠지는 ..

예외의 상세 메시지에 최대한 많은 것을 담자 👌 예외의 상세 메시지 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다. 스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열로, 보통은 예외의 클래스 이름 뒤에 상세 메시지가 붙는 형태다. 이러한 상세 메시지는 실패 원인에 관한 정보를 가능한 한 많이 담아 반환하므로, 사후 분석을 위해 실패 순간의 상황을 정확히 포착해 예외의 상세 메시지에 담아야 한다. 즉, 실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다. 하지만 보안과 관련한 정보는 스택 추적 정보를 많은 사람이 볼 수 있으므로, 상세 메시지에 비밀번호나 암호 키 ..

검사 예외든, 비검사 예외든, 추상 메서드든, 구체 메서드든 메서드가 던질 가능성이 있는 모든 예외를 문서화하라. 🐱‍👤 검사예외 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자. 만약, 공통 상위 클래스 하나로 예외를 뭉뚱그려 선언한다면 메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못할뿐더러, 같은 맥락에서 발생할 여지가 있는 다른 예외들까지 삼켜버릴 수 있어 API 사용성을 크게 떨어뜨린다. (하지만 오직 JVM만이 호출하는 main 메서드는 예외다. Exception을 던지도록 선언해도 괜찮음) 🐱‍💻 비검사예외 자바 언어가 요구하는 것은 아니지만, 비검사 예외도 검사 예외처럼 문서화해두면 도움이 된다. 잘 정비된..

생성자나 정적 팩토리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는 것이 더 좋다. ⛔ 기존 문제점 정적 팩터리와 생성자에는 똑같은 제약이 하나 있다. 선택적 매개변수가 많을 때 적절히 대응하기 어렵다. 보통 필수 매개변수와 선택 매개변수가 있을 때 필수 매개변수와 선택 매개변수를 1개 받는 생성자, 2개 받는 생성자, 3개 받는 생성자 등의 형태로 선택 매개변수를 전부 다 받는 생성자까지 늘려가는 방식을 사용한다. 하지만 이런 생성자는 매개변수 개수가 많아지면 - 클라이언트 코드를 작성하거나 읽기 어렵고, - 코드를 읽을 때 각 값의 의미가 무엇인지 헷갈리고, - 매개변수가 몇 개인지 주의해서 세어보아야 하고, - 클라이언트가 실수로 매개변수의 순서를 바꿔 건네줘도 컴파일러는 알아채지 못하고, ..