[Clean Code] 7장 오류 처리

TIL (Today I Learned)

22.03.04~22.03.05

오늘 읽은 범위

7장 오류 처리

책에서 기억하고 싶은 내용

오류 코드보다 예외를 사용하라

// 오류 코드 사용
public void sendShutDown() {
	DeviceHandle handle = getHandle(DEV1);
	if (handle != DeviceHandle.INVALID) { ... }
}

// 예외 사용
public void sendShutDown() {
	try {
		DeviceHandle handle = getHandle(DEV1);
	} catch (DeviceShutDownError e) { 
    	logger.log(e);
    }
}

 

try-catch-finally 문부터 작성하라

try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. 그러므로 예외가 발생한 코드를 짤 때는 try-catch-finally문으로 시작하는 편이 낫다. 그러면 try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다.

 

테스트를 만들 때는 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다.

 

미확인 예외를 사용하라

checked exception은 OCP를 위반한다. 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부에 모두 해당 예외를 정의해야 한다. 모듈과 관련된 코드가 전혀 바뀌지 않았음에도 불구하고 (선언부가 바뀌었으므로) 모듈을 다시 빌드한 다음 배포해야 한다는 말이다. 

 

throws 경로에 위치하는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다. 

 

예외에 의미를 제공하라

오류 메시지에는 실패한 연산 이름, 실패 유형 등의 정보를 담아 예외와 함께 던진다. 애플리케이션이 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 넘겨준다. 

 

호출자를 고려해 예외 클래스를 정의하라

호출하는 라이브러리 API를 감싸면서 예외 유형을 하나 정의한다.

외부 API를 감쌀 때의 장점

1) 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어들기 때문에 나중에 다른 라이브러리로 갈아타도 비용이 적다.

2) 감싸기 클래스에서 외부 API를 호출하는 대신 테스트 코드를 넣어주는 방법으로 프로그램을 테스트하기도 쉬워진다.

3) 프로그램이 사용하기 편한 API를 정의할 수 있기 때문에 특정 업체가 API를 설계한 방식에 영향을 받지 않는다.

ACMEPort port = new ACMEPort(12);

try {
    port.open();
} catch (DeviceResponseException e) {
    reportPortError(e);
    logger.log("Device response exception", e);
} catch (또 다른 exception) { ... } {
} catch (또 다른 exception) { ... )

 

ACMEPort port = new ACMEPort(12);

try {
    port.open();
} catch (PortDeviceFailure e) {
    reportPortError(e);
    logger.log(e.getMessage(), e);
} finally { ... }

----

public class LocalPort {
	private ACMEPort innerPort;
    
    public LocalPort(int portNumber) {
    	innerPort = new ACMEPort(portNumber);
    }
    
    public void open() {
    	try {
        	innerPort.open();
        } catch (DeviceResponseException e) {
        	throw new PortDeviceFailure(e);
        } catch (또 다른 에러 e) {
        	throw new PortDeviceFailure(e);
        }
    }
}

 

정상 흐름을 정의하라

클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 Special Case Pattern을 이용하면 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하기 때문에 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.

 

null을 반환하지 마라

메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다. 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다.

Collections.emptyList()를 잘 활용해보자

 

null을 전달하지 마라

인수로 null이 넘어오면 코드에 문제가 있다는 말이다. 

1) 예외 유형을 만들어 반환

2) assert문을 사용

이 두 방법은 문제를 완전히 해결하지 못한다. 원인 함수를 잘 파악해보자. 

 

오늘 읽은 소감

NullPointException을 자주 발생시켰는데, 아예 null값이 돌아오지 않도록 개발해야 한다는 점이 놀라웠다. 그리고 프로젝트를 개발할 때 null 관련 에러가 뜰 경우 IDE에서 assert문을 삽입하라는 팝업창이 떠서 종종 넣곤 했는데, 그냥 IDE 오류만 사라질 뿐 null 에러를 완전히 막지는 못해서 어리둥절했던 기억이 있다. 오늘에서야 겨우 assert문을 검색해봤는데 가급적 사용하지 말라는 말이 있어서 놀랐다. 지금 코드 리팩토링 중인데 고쳐야 할 게 늘어서 기쁘다^^

앞으로는 null 처리를 어떻게 할 지 고민하는 것보다 원인 코드를 잘 탐구해서 어떻게든 객체나 클래스를 반환하도록 해야겠다.

 

궁금하거나 잘 이해되지 않는 내용

확인된 예외(checked exception)

RuntimeException을 상속하지 않고 꼭 처리해야 하는 exception

미확인 예외(unchecked exception)

명시적으로 처리하지 않아도 되는 exception

https://devlog-wjdrbs96.tistory.com/351

[Java] Checked Exception vs Unchecked Exception 정리

 

assert

코드가 실행될 때 반드시 어떤 값일지 확신하는 값, 범위 또는 확실한 클래스의 상태 등을 체크하여 프로그램의 신뢰성을 높이기 위해서 사용된다. 하지만 되도록이면 사용을 자제하자

"you have to think about ... assert is turned off" If you need to do that, you are doing it wrong. "asserts are a premature optimization of limited use"

https://offbyone.tistory.com/294

Java에서 assert 사용하기

https://stackoverflow.com/questions/2758224/what-does-the-java-assert-keyword-do-and-when-should-it-be-used

What does the Java assert keyword do, and when should it be used?

 

특수 사례 패턴

특수 사례를 처리하는 non-null 객체나 클래스를 반환한다. 

https://java-design-patterns.com/patterns/special-case/

Special Case