[자바 코딩의 기술] 5장 : 문제 발생에 대비하기

5.1 빠른 실패

문제 코드

class CruiseControl {
    static final double SPEED_OF_LIGHT_KMH = 1079252850;
    static final double SPEED_LIMIT = SPEED_OF_LIGHT_KMH;

    private double targetSpeedKmh;

    void setTargetSpeedKmh(double speedKmh) {
        if (speedKmh < 0) {
            throw new IllegalArgumentException();
        } else if (speedKmh <= SPEED_LIMIT) {
            targetSpeedKmh = speedKmh;
        } else {
            throw new IllegalArgumentException();
        }
    }

 

 

위 코드는 else if의 정상적인 실행 흐름에 앞 뒤로 예외 처리 조건이 들어가있어 정상적인 실행 흐름이 눈에 띄지 않는다.

 

또한, 두 번째 조건은 !(speedKmh <= 0) && speedKmh <= SPEED_LIMIT 으로 해석되어야 하고

세 번째 조건은 !(두번째조건)으로 해석되어야 한다.

 

이러한 과정은 JVM에게는 무척 간단하지만 인간에게는 그렇지 않다.

 

코드를 개선하려면 어떻게 해야 할까?

개선 코드

class CruiseControl {
    static final double SPEED_OF_LIGHT_KMH = 1079252850;
    static final double SPEED_LIMIT = SPEED_OF_LIGHT_KMH;

    private double targetSpeedKmh;

    void setTargetSpeedKmh(double speedKmh) {
    	// 매개변수 검증
        if (speedKmh < 0 || speedKmh > SPEED_LIMIT) {
            throw new IllegalArgumentException();
        }

	// 일반적인 경로
        targetSpeedKmh = speedKmh;
    }
}

'검증' 과 '정상적인 경로'를 분리함.

 

'검증'이 먼저 실행되어 예외 상황이라면 빠르게 실패한다.

그러면 이 후에 이어지는 흐름은 '정상적인 흐름'이 된다.

5.2 항상 가장 구체적인 예외 잡기

문제 코드

class TransmissionParser {
    static Transmission parse(String rawMessage) {
        if (rawMessage != null
                && rawMessage.length() != Transmission.MESSAGE_LENGTH) {
            throw new IllegalArgumentException("Bad message received!");
        }

        String rawId = rawMessage.substring(0, Transmission.ID_LENGTH);
        String rawContent = rawMessage.substring(Transmission.ID_LENGTH);
        try {
        	// rawId 문자열 안에 int형으로 바꿀 수 없는 문자가 있을 때 오류가 발생!!
            int id = Integer.parseInt(rawId);
            String content = rawContent.trim();
            return new Transmission(id, content);
        } catch (Exception e) {
            throw new IllegalArgumentException("Bad message received!");
        }
    }
}

위 코드는 예외를 'Exception'으로 받고 있다. 'Exception'은 자바의 가장 일반적인 예외 유형이다.

그렇기 때문에 우리가 잡길 원하는 예외 이외에 NullPointerException같은 일반적인 오류를 잡을 수 있다.

 

우리는 좀 더 구체적인 예외를 잡을 수 있도록 코드를 개선해야만 한다.

 

개선 코드

class TransmissionParser {
    static Transmission parse(String rawMessage) {
        if (rawMessage != null &&
                rawMessage.length() != Transmission.MESSAGE_LENGTH) {
            throw new IllegalArgumentException("Bad message received!");
        }

        String rawId = rawMessage.substring(0, Transmission.ID_LENGTH);
        String rawContent = rawMessage.substring(Transmission.ID_LENGTH);
        try {
        	// 예외 발생!!
            int id = Integer.parseInt(rawId);
            //
            
            String content = rawContent.trim();
            return new Transmission(id, content);
        } catch (NumberFormatException e) { // 예외 구체화
            throw new IllegalArgumentException("Bad message received!");
        }
    }
}

위 코드에서는  parseInt에서 숫자가 아닌 값이 있을 때 예외가 발생하므로 'NumberFormatException'이 발생하게 된다.

따라서 catch 조건에 이를 추가해준다. ---> 가장 구체적인 예외를 잡자!!

 

만약 여러 개의 예외를 똑같은 방법으로 처리한다면 다중 캐치 방식을 사용하자.

ex) catch(NumberFormatException | IOException)

5.3 메시지로 원인 설명

예외를 구체화하면 발생 타입만 봐도 무엇이 잘못되는지 알아챌 수 있다. 

    - 메서드에 잘못된 매개변수 입력 => IlleagalArgumentException 발생

 

하지만 여기까지만 하면 예외 발생 전후 맥락을 알 수가 없다.

 

예외 message를 좀 더 자세하게 추가해 예외 자체로 맥락을 알 수 있게 해보자.

 

개선 코드

class TransmissionParser {
    static Transmission parse(String rawMessage) {
        if (rawMessage != null
                && rawMessage.length() != Transmission.MESSAGE_LENGTH) {
            throw new IllegalArgumentException(
            	// 메시지 구체화
                String.format("Expected %d, but got %d characters in '%s'",
                    Transmission.MESSAGE_LENGTH, rawMessage.length(),
                    rawMessage));
        }

        String rawId = rawMessage.substring(0, Transmission.ID_LENGTH);
        String rawContent = rawMessage.substring(Transmission.ID_LENGTH);
        try {
            int id = Integer.parseInt(rawId);
            String content = rawContent.trim();
            return new Transmission(id, content);
        } catch (NumberFormatException e) {
            throw new IllegalArgumentException(
            	// 메시지 구체화
                String.format("Expected number, but got '%s' in '%s'",
                        rawId, rawMessage));
        }
    }
}

1. 정보를 누락하거나 쓸모없는 정보를 제공하는 대신 바라는 정보

2. 받은 것

3. 전체 맥락

 

이 세가지 요소를 메시지로 전달하면 개발자는 예외의 근본적이 원인을 더 빨리 추적할 수 있다.

5.4 원인 사슬 깨지 않기

예외는 또 다른 예외를 발생시킬 수 있다. 이때 다시 예외를 던져야한다.

이런 과정을 통해 각 예외가 그 예외를 일으킨 예외와 연결된 리스트를 보여주는 스택 추적을 확인할 수 있다.

 

그렇다면 어떻게 원인 사슬을 깨지 않고 유지할 수 있을까?

class TransmissionParser {
    static Transmission parse(String rawMessage) {
        if (rawMessage != null
                && rawMessage.length() != Transmission.MESSAGE_LENGTH) {
            throw new IllegalArgumentException(
                String.format("Expected %d, but got %d characters in '%s'",
                    Transmission.MESSAGE_LENGTH, rawMessage.length(),
                    rawMessage));
        }

        String rawId = rawMessage.substring(0, Transmission.ID_LENGTH);
        String rawContent = rawMessage.substring(Transmission.ID_LENGTH);
        try {
            int id = Integer.parseInt(rawId);
            String content = rawContent.trim();
            return new Transmission(id, content);
        } catch (NumberFormatException e) {
            throw new IllegalArgumentException(
                String.format("Expected number, but got '%s' in '%s'",
                        rawId, rawMessage));
        }
    }
}

catch 블록에서 예외를 던질 때 message와 잡았던 예외를 즉시 원인으로 전달하도록 한다.

 

<EXAMPLE>

 throw new IllegalArgumentException("Message", e);

5.5 변수로 원인 노출

**어렵고 이해 잘 안됨**

 

맞춤형 예외를 만들어 그 예외만의 메시지 필드가 들어간 예외 클래스를 정의하여 사용하면 된다.

향후 이 클래스의 필드를 쉽게 추출할 수 있다.

5.6 타입 변환 전에 항상 타입 검증하기

Object signal = inputStream.readObject();
CrewMessage crewMessage = (CrewMessage) signal;

위 코드는 스트림이 항상 CrewMessage 객체로 들어올 때만 올바르게 동작한다.

만약, 그 외의 객체가 들어오게 된다면 스트림에선 문제가 발생하지 않지만 cast 예외가 발생하게된다.

 

이러한 예외가 발생하지 않도록 코드를 수정해야한다.

Object signal = inputStream.readObject();
if (signal instanceof CrewMessage) {
    CrewMessage crewMessage = (CrewMessage) signal;
}

'instanceof' 연산자로 타입을 검증하면 문제를 해결할 수 있다.

만약 singnal의 타입이 CrewMessage면 true를 반환하고 그 외는 false를 반환하기 때문이다.

 

결국, 참일때만 반환하기 때문에 ClassCastException이 발생하지 않는다.

5.7 항상 자원 닫기

class Logbook {

    static final Path LOG_FOLDER = Paths.get("/var/log");
    static final String FILE_FILTER = "*.log";

    List<Path> getLogs() throws IOException {
        List<Path> result = new ArrayList<>();

        DirectoryStream<Path> directoryStream =
                Files.newDirectoryStream(LOG_FOLDER, FILE_FILTER);
        for (Path logFile : directoryStream) {
            result.add(logFile);
        }
        directoryStream.close();

        return result;
    }
}

DirectoryStream을 열고 close()로 닫는 행동을 볼 수 있다. 문제가 무엇일까?

 

문제는 프로그램이 자원을 연 후 close()로 자원을 해제하기 전에 자원을 사용하다가 예외가 발생하는 경우다. 이 경우 예외로 인해 close()가 제대로 실행되지 않을 수 있다.

--> '자원 누출'이라 부름

 

그렇다면 어떻게 사용했던 자원을 항상 닫을 수 있을까?

class Logbook {

    static final Path LOG_FOLDER = Paths.get("/var/log");
    static final String FILE_FILTER = "*.log";

    List<Path> getLogs() throws IOException {
        List<Path> result = new ArrayList<>();

        try (DirectoryStream<Path> directoryStream =
                     Files.newDirectoryStream(LOG_FOLDER, FILE_FILTER)) {
            for (Path logFile : directoryStream) {
                result.add(logFile);
            }
        }

        return result;
    }
}

방법은 간단하다.  try 문 안에 자원 열면된다.

이 경우 try 문이 종료되면 자바가 알아서 close()호출을 실행한다.

 

사실 try, finally에서 finally 부분에서 close()가 실행되지만 우리는 컴파일러가 해주므로 그냥 try문만 사용하도록 하자.

5.8 항상 다수 자원 닫기

여러 자원을 동시에 사용하면 자원 닫기가 더욱 어렵다.

 

각 자원마다 모종의 이유로 실패할 수 있기 때문에 다수 자원을 항상 닫기가 쉽지않은 것이다.

 

이때 try-with-resources를 사용하면 좋다.

자원을 try문 안에서 열기만 하면 알아서 각 자원을 닫아준다.

 

자원을 직접 관리하지 말고 꼭 try-with-resources 블록 안에서 자원을 열자!

5.9 빈 catch 블록 설명하기

        try (DirectoryStream<Path> directoryStream =
                     Files.newDirectoryStream(LOG_FOLDER, FILE_FILTER)) {
            for (Path logFile : directoryStream) {
                result.add(logFile);
            }
        } catch (NotDirectoryException e) {

        }

빈 catch 블록에는 도대체 어떤 의도가 숨어있을까??

 

    List<Path> getLogs() throws IOException {
        List<Path> result = new ArrayList<>();

        try (DirectoryStream<Path> directoryStream =
                     Files.newDirectoryStream(LOG_FOLDER, FILE_FILTER)) {
            for (Path logFile : directoryStream) {
                result.add(logFile);
            }
        } catch (NotDirectoryException ignored) {
            // No directory -> no logs!
        }

        return result;
    }

 

추가하면 좋은 것

-> 빈 catch 인 이유 ( 주석 설명 추가)

-> 명시적으로 드러내기 (e -> ignored)

 

ignored로 예외를 무시하겠다고 명시하기.

주석으로 왜 예외를 무시하는지 설명하기.

 

5.10 5장에서 배운 내용

어떤 프로그램을 작성하든 예외 처리는 필수이다.

 

예외를 '원인 사슬'로 연결하지 않거나 '자원을 닫지 않는 것' 등의 세부적인 요소에서 예외가 쉽게 발생하고 오동작할 수있다.

 

하지만, 이러한 실수를 저질러도 컴파일은 되기 때문에 문제를 나중에 알게 되고 추적하기도 더욱 어려워진다.

 

5장에서는 파일 처리나 네트워킹 처럼 불가피하게 제어할 수 없는 부분들의 오류를 처리하는 방법을 배웠다.

 

6장에서는 프로그램을 올바르게 기능하게 하기 위해 시도하는 가장 중요한 도구인 '단위 테스트'에 대해 학습한다.