클린코드 (6) - 오류 처리

gentledot·2021년 6월 12일

도서를 읽고서 클린코드

코드 품질에 대한 고찰

목록 보기

8/13

오류 처리

뭔가 잘못될 가능성은 늘 존재한다. → 뭔가 잘못되면 바로 잡을 책임은 바로 프로그래머에게 있다.
깨끗한 코드와 오류 처리는 연관성이 있음
- 흩어진 오류 처리 코드로 인해 실제 코드가 하는 일을 파악하기가 거의 불가능하다.
- 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.
오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다.
오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다.

처음 Spring을 접했을 때는 throws Exception 구문이 method 마다 붙어 있어서 예외를 던지는 것이 기본 작성 방법으로 이해했었습니다.

예외(Exception)는 코드 오류로 컴파일 과정에서 발생할 수 있고 로직 오류로 런타임 과정에서 발생할 수 있습니다.

어떤 예외가 되었든 발생된 예외 대해서는 가급적 미리 파악할 수 있으면 좋고 예외가 발생할 때 잘 인지할 수 있도록 대비해 두는 것이 좋으며, 발생한 예외를 대할 때는 바로 잡을 책임을 갖고 코드 보수를 진행해야 한다고 들었습니다.

오류 코드보다 예외를 사용

예외를 지원하지 않는 경우 오류를 처리할 때 오류코드를 반환하는 방법이 전부

오류 코드를 반환하는 방식

public class DeviceController {
		...
    public void sendShutDown() {
        DeviceHandle handle = getHandle(DEV1);
        // 디바이스 상태를 점검한다.
        if (handle != DeviceHandle.INVALID) {
            // 레코드 필드에 디바이스 상태를 저장한다.
            retrieveDeviceRecord(handle);
            // 디바이스가 일시정지 상태가 아니라면 종료한다.
            if (record.getStatus() != DEVICE_SUSPENDED) {
                pauseDevice(handle);
                clearDeviceWorkQueue(handle);
                closeDevice(handle);
            } else {
                logger.log("Device suspended. Unable to shut down");
            }
        } else {
            logger.log("lnvalid handle for: " + DEV1.toString());
        }
    }
    // ...
}

호출자 코드가 복잡함 → 함수를 호출한 즉시 오류를 확인해야 함

오류 발생 시 예외를 던지는 코드

public class DeviceController {
    public void sendShutDown() {
        try {
            tryToShutDown();
        } catch (DeviceShutDownError e) {
            logger.log(e);
        }
    }

    private void tryToShutDown() throws DeviceShutDownError {
        DeviceHandle handle = getHandle(DEV1);
        DeviceRecord record = retrieveDeviceRecord(handle);

        pauseDevice(handle);
        clearDeviceWorkQueue(handle);
        closeDevice(handle);
    }

    private DeviceHandle getHandle(DeviceID id) {
        ...
        throw new DeviceShutDownError("Invalid handle for : " + id.toString());
        ...
    }
    ...
}

코드 가독성 상승, 코드 품질 상승 도모

Try-Catch-Finally 문부터 작성하자

예외에서 프로그램 안에 범위를 정의한다는 사실
- try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어감
- try 블록은 transaction과 비슷
try 블록에서 무슨 일이 생기든 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
- try에서 무슨 일이 생기든 호출자가 기대하는 상태를 정의하기 쉬워진다.

try 블록은 transaction과 비슷하다는 의미를 실행 로직이 정상적으로 생성되지 않을 때 rollback 처리를 통해 의도치 않은 동작을 방지하는 부분과 비슷한 의미로 이해하였습니다.

파일을 열어 직렬화된 객체 몇 개를 읽어들이는 코드 작성

단위 테스트 작성

  @Test(expected = StorageException.class)
  public void retrieveSectionShouldThrowOnlnvalidFileName() {
      sectionStore.retrieveSection("invalid - file");
  }

@Test(expected = StorageException.class) 는 해당 테스트를 실행하면 StorageException이 발생되면 Test Passed 라는 의미입니다.

작성된 단위 테스트에 맞춰 코드 구현

  public List<RecordedGrip> retrieveSection(String sectionName) {
    // 실제로 구현할 때까지 비어 있는 더미를 반환한다.
    return new ArrayList<RecordedGrip>();
  }

코드가 예외를 던지지 않으므로 단위 테스트는 실패

잘못된 파일 접근을 시도하는 케이스 구현

public List<RecordedGrip> retrieveSection(String sectionName) {
    try {
        Fileinputstream stream = new FileInputStream(sectionName);
    } catch (Exception e) {
        throw new StorageException("retrieval error", e);
    }
    return new ArrayList<RecordedGrip>();
}

케이스 구현 코드 리팩토링

catch 블록에서 예외 유형을 좁혀 실제 FileInputStream 생성자가 던지는 FileNotFoundException을 잡아냄

public List<RecordedGrip> retrieveSection(String sectionName) {
    try {
        Fileinputstream stream = new FileInputStream(sectionName);
        stream.close();
    } catch (FileNotFoundException e) {
        throw new StorageException("retrieval error", e);
    }
    return new ArrayList<RecordedGrip>();
}

try-catch 구조로 범위를 정의했으므로 TDD를 사용해 필요한 나머지 논리를 추가한다.
- 나머지 논리는 FileInputStream을 생성하는 코드와 close 호출문 사이에 넣으며 오류나 예외가 전혀 발생하지 않는다고 가정
테스트 케이스 작성 시 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장
- 자연스레 try 블록의 transaction 범위부터 구현하게 되므로 범위 내에서 transaction 본질을 유지하기 쉬워진다.

여기서 더 보완을 한다면
1. try-with-resource 구문을 활용하여 FileInputStream을 열고 transaction 실행 후 닫힐 수 있도록 처리할 수 있을 것 같습니다.
2. new ArrayList<RecordedGrip>(); 은 try 밖에 empty list를 생성해두고 transaction을 정상적으로 통과하면 비어 있지 않은 리스트를 리턴하도록 구성하여 빈 list를 전달 받았을 때 대비할 수 있도록 구성이 가능할 것 같습니다.

미확인 예외(Unchecked Exception)을 사용하라

확인된 예외(Checked Exception)
- method가 반환할 예외를 모두 열거
- method가 반환하는 예외는 method 유형의 일부
- 코드가 method를 사용하는 방식이 method 선언과 일치하지 않으면 컴파일 불가
지금은 안정적인 소프트웨어를 제작하는 요소로 확인된 예외가 반드시 필요하지는 않다.
- C#, C++, Python, Ruby 은 확인된 예외를 지원하지 않지만 안정적인 소프트웨어 구현에 무리가 없다.
Checked Exception이 치르는 비용
- OCP(Open Closed Principle)를 위반한다.
  - 확인된 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 메서드 모두가 선언부에 해당 예외를 정의해야 한다. → 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다...
  - 확인된 오류를 받기 위해 모든 함수 선언부에 thows 절을 추가해야 함
    - 대규모 시스템에서 호출이 일어나는 방식 ⇒ 최상위 함수가 아래 함수를 호출 → 아래 함수를 호출 → ... → 최하위 함수를 호출
    - 최하위 함수가 새로운 오류를 던진다 가정하면???
      - 함수 모두가 catch 블록에서 새로운 예외를 처리하거나
      - 선언부에 throw 절을 추가해야 한다.
      - 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다.
확인된 예외가 유용할 때도 있음
- 중요한 라이브러리를 작성할 땐 모든 예외를 잡아야 함
일반적인 App.은 의존성이라는 비용이 이익보다 크다.

checked Exception (Exception을 상속 받아 구현된 클래스들)가 정의된 객체를 다루려면 이에 대해 catch가 선언되거나 throws 절로 상위 객체에 넘길 수 밖에 없습니다.
코드가 변경될 때 정의한 예외를 변경해야하기 때문에 예외를 Exception.class로 퉁치게 되면 넘기는 입장에선 편하겠지만 어떠한 예외에 대해 대처해야하는지 바로 인지하기 어렵기 때문에 무책임한 행위라고 생각합니다.

예외 발생으로 사용자의 요청 동작을 중단시킬 것인지 불완전한 동작이라도 계속 동작할 수 있도록 유지할 것인지에 대한 구분에 따라 Checked / Unchecked Exception을 설정해야 한다고 생각합니다.

예외에 의미를 제공하라

예외를 던질 때 전후 상황을 충분히 덧붙인다.
- 오류가 발생한 원인과 위치를 찾기가 쉬워진다.
- 자바는 모든 예외에 호출 스택을 제공하지만 실패한 코드의 의도를 파악하려면 부족함.
로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 넘겨준다
- 오류 메시지에 정보를 담아 예외를 함께 던진다.
- 실패한 연산 이름과 실패 유형도 언급

Logger를 사용한다면 logger.warn("message", e); 형식과 같이 예외 객체('e')도 param에 포함하여 작성하면 정의한 메시지와 함께 호출 stack에 대한 로그도 출력됩니다.

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

오류를 분류하는 방법
- 오류가 발생한 위치
  - ex) 오류가 발생한 component로 분류
- 오류의 유형
  - ex) 디바이스 실패, 네트워크 실패, 프로그래밍 오류 등으로 분류
오류를 정의할 때 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.

오류를 형편없이 분류한 사례

ACMEPort port = new ACMEPort(12);
try {
    port.open();
} catch (DeviceResponseException e) {
    reportPortError(e);
    logger.log("Device response exception", e);
} catch (ATM1212UnlockedException e) {
    reportPortError(e);
    logger.log('Unlock exception", e);
} catch (GMXError e) {
    reportPortError(e);
    logger.log("Device response exception");
} finally {
    ...
}

대다수 상황에서 오류를 처리하는 방식은 (오류를 일으킨 원인과 무관하게) 비교적 일정하다.
- 오류를 기록한다.
- 프로그램을 계속 수행해도 좋은지 확인한다.

코드를 간결하게 고치면...
```
ACMEPort port = new ACMEPort(12);
try {
    port.open();
} catch (PortDeviceFailure e) {
    reportError(e);
    logger.log(e.getMessage(), e);
} finally {
    ...
}
```
- 위 경우는 예외에 대응하는 방식이 예외 유형과 무관하게 거의 동일하므로 예외 유형 하나를 반환하는 식으로 간결하게 고칠 수 있음

LocalPort class는 단순히 ACMEPort class가 던지는 Exception을 잡아 변환하는 감싸기(wrapper) class일 뿐

public class LocalPort {
	private ACMEPort innerPort;

	public LocalPort(int portNumber) {
		innerPort = new ACMEPort(portNumber);
	}
	
	public void open() {
		ACMEPort port = new ACMEPort(12);
      try {
          port.open();
      } catch (DeviceResponseException e) {
         new PortDeviceFailure(e);
      } catch (ATM1212UnlockedException e) {
         new PortDeviceFailure(e);
      } catch (GMXError e) {
	 new PortDeviceFailure(e);
      } finally {
          ...
      }
	}
}

LocalPort class처럼 ACMEPort를 감싸는 클래스는 매우 유용
- 실제로 외부 API를 사용할 때는 감싸기 기법이 최선.
port 디바이스 실패를 표현하는 예외 유형 하나를 정의하여 프로그램이 깨끗해짐.

외부 API를 감싸면
- 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다
- 나중에 다른 라이브러리로 갈아타도 비용이 적다
- 감싸기 클래스에서 외부 API를 호출하는 대신 테스트 코드를 넣어주는 방법으로 프로그램을 테스트하기도 쉬워진다.
- 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다. (프로그램이 사용하기 편리한 API를 정의하면 그만.)
예외 클래스가 하나만 있어도 충분한 코드가 많음. (예외 클래스에 포함된 정보로 오류를 구분해도 괜찮은 경우)
한 예외는 잡아내고 다른 예외는 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용한다.

정리하면

예외 유형에 큰 구분이 필요하지 않다면 상위 예외를 catch

예외를 다루는 작업이 일정하다면 일정한 동작을 method나 handler 객체에서 다뤄질 수 있도록 리팩토링 (나중에 예외 처리 방식 변경에 유용)

처음부터 상위 예외를 catch하지 않고 발생할 수 있는 예외 유형별로 catch할 수 있도록 우선 구성해두는게 좋은 것 같습니다.

정상 흐름을 정의하라

비즈니스 논리와 오류 처리가 잘 분리된 코드
- 간결한 알고리즘 확보도 중요하지만 오류 감지가 프로그램 언저리로 밀려난다.
- 외부 API를 감싸 독자적인 예외를 던지고, 코드 위에 처리기를 정의해 중단된 계산을 처리
- 중단이 적합하지 않은 경우도 존재
비용 청구 애플리케이션 - 총계 계산
```
try {
		MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
		fn_total += expenses. getTotal();
} catch(MealExpensesNotFound e) { 
		m_total += getMealPerDiem();
}
```
- 식비를 비용으로 청구했다면 직원이 청구한 식비를 총계에 더한다.
- 식비를 비용으로 청구하지 않았다면 일일 기본 식비를 총계에 더한다.
- 그런데, 예외가 논리를 따라가기 어렵게 만든다.

개인적으로 catch에 있는 로직에 대해서는 의도를 명확히 파악하지 않는 이상 로직과 분리된 별도 예외 처리로직으로 읽히기 때문에 예외 발생 시 다른 로직을 처리하는 경우라면 최소한 주석을 정리해주었으면 좋겠습니다. ㅠㅠ

특수 사례 패턴 (Special case pattern) 사용
```
public class PerDiemMealExpenses implements MealExpenses {
		public int getTotal() {
		// 기본값으로 일일 기본 식비믎 반환한다.
		}
}
```
- 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식
- 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.
  - 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하기 때문

특수 사례 패턴이라는 의미를 객체 동작의 예외로 처리하지 않고 또 다른 동작으로 처리할 수 있도록 세부 동작 객체를 구현하는 방식으로 이해하였습니다.

Null을 반환하지 마라

null 반환 예

public void registeritem(Item item) {
	if (item != null) {
            ItemRegistry registry = peristentStore.getItemRegistry();
            if (registry != null) {
                Item existing = registry.getItem(item.getID());
                if (existing.getBillingPeriocK).hasRetailOwner()) {
                    existing.register(item);
                 }
            }
        }
}

null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다
null 확인을 빼먹는다면 application이 통제 불능에 빠질 수도 있음.
existing 에 대한 null 확인이 누락되었기 때문에 NullPointerException이 발생할 가능성이 존재
null 확인이 누락된 것이 문제??? 실상은 null 확인이 너무 많은 것이 문제!

null 반환보다는 예외를 던지거나 특수 사례 객체를 반환한다.
사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 패턴 객체를 반환하는 방식을 고려할 것.

null 반환 코드를 리팩토링 하는 예

  List<Employee> employees = getEmployees();
  if (employees != null) {
      for(Employee e : employees) {
          totalPay += e.getPay();
      }
  }

반드시 null을 반환할 필요가 있을까?

getEmployees()를 변경해 빈 리스트를 반환한다면 코드가 깔끔해짐

List<Employee> employees = getEmployees(); // List.isEmpty() = true
for(Employee e : employees) {
		totalPay += e.getPay();
}
// employees list 내 item이 없으므로 loop는 동작하지 않음.

Collections.emptyList()를 활용해 빈 리스트를 반환

public List<Employee> getEmployees() {
		if ( .. 직원이 없다면 .. )
				return Collections.emptyList();
}

null과 NullPointerException은 철천지 원수같이 다뤄야한다고 생각합니다. java에서 개발자가 접하는 유일한 pointer가 NullPointer라는 것도 흠...

null은 클래스 내부에서 처리하고 다른 곳에 무책임하게 넘기지 않아야 한다고 생각합니다. 받아서 사용하는 입장에서 모든 전달 받는 값에 null이 있다는 가정을 갖고 의심해야 한다는 것부터 구현해야 할 비즈니스 로직에 집중할 수 없게 된다고 봅니다.

빈 상태를 전달해야 한다면 Optional 객체를 권장드립니다. null을 Optional.ofNullable()에 담아두면 isPresent()를 통해 빈 상태를 바로 확인해 볼 수 있고 orElseThrow() 를 통해 부적절한 객체에 대해 예외로 대응하기 용이하기 때문입니다.

Null을 전달하지 마라

method로 null을 전달하는 방식도 나쁘다.
정상적인 인수로 null을 기대하는 API가 아니라면 method로 null을 전달하는 코드는 최대한 피한다.

null 전달의 예 (두 지점 사이의 거리를 계산하는 method)

public class MetricsCalculator {
    public double xProjection(Point p1, Point p2) {
        return (p2.x - p1.x) * 1.5;
    }
    ...
}

calculator.xProjection(null, new Point(12, 13)); → NullPointerException이 발생

새로운 예외 유형을 만들어 던진다면?

public class MetricsCalculator {
    public double xProjection(Point p1, Point p2) {
        if (p1 == null || p2 == null) {
            throw InvaildArgumentException("Invalid argument for MetricsCalculator.xProjection");
        }
        return (p2.x - p1.x) * 1.5;
    }
    		...
}

NullPointerException 보다는 조금 나을지도 모르겠지만...
- 위 코드는 InvaildArgumentException을 잡아내는 처리기가 필요하다.
- 처리기는 InvaildArgumentException 예외를 어떻게 처리해야 하는지 대비되어야 한다.

assert 문을 사용하는 방법은?

public class MetricsCalculator {
    public double xProjection(Point p1, Point p2) {
        assert p1 != null : "p1 should not be null";
        assert p2 != null : "p2 should not be null";

        return (p2.x - p1.x) * 1.5;
    }
    		...
}

문서화가 잘 되어 코드 읽기는 편하지만 문제를 해결하지는 못한다.
- 누군가 null을 전달하면 여전히 실행 오류가 발생함

애초에 null을 넘기지 못하도록 금지하는 정책이 합리적임
- 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다.
- 인수로 null이 넘어오면 코드에 문제가 있다는 이야기.
- 이런 정책을 따르면 그만큼 부주의한 실수를 저지를 확률도 작아진다.

null이 없는 값을 parameter로 전달받을 수 있다면 가장 좋겠지만 그러지 못한다면 parameter와 return 값에 null에 대한 대비를 하는 것이 최선이라 생각합니다.

parameter :

assert로 단언을 설정하거나

적절한 UncheckedException을 호출하도록 설정 (IllegalArgumentException 등)

google guava의 checkArgument 가 적절한 예가 될 것 같습니다.

Guava_Preconditions - baeldung

return :

Optional 객체에 감싸서 return

빈 Optional 객체를 전달받은 경우 적절한 예외를 호출하도록 대비하거나 기본값으로 설정되도록 구현이 용이하기 때문입니다.

java.util.Optional<T> - Java API Docs.