깨끗한 코드를 작성하는 방법을 다루는 책에서 오류 처리를 논하는 장이 있어 이상할 수도 있다. 그러나 오류처리는 깨끗한 코드를 작성하는 것과 연관성이 있다. 오류 처리는 프로그램에 반드시 필요한 요소중 하나이기 때문이다. 어떠한 변수로 인해 로직이 실패할지 모르기 때문이다. 무언가 잘못될 가능성은 언제나 존재한다. 잘못을 바로 잡을 책임은 프로그램을 구현한 우리 프로그래머에게 있다.
오류 처리는 모든 로직에 포함된다고 해도 과언이 아니다. 오류 처리 코드를 잘 작성하지 못해 여기저기 흩어진다면 실제 코드가 하는 일을 파악하기가 힘들어져 프로그램 논리를 이해하는데 방해된다. 이번 7장에서는 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지가 소개된다.
오류 코드보다 예외를 사용하라
과거에는 예외를 지원하지 않는 프로그래밍 언어가 많았다고 한다. 때문에 오류를 처리하고 보고하는 방법이 상당히 제한적이었다. 직접 if문을 사용하여 오류 플래그를 만들고 오류코드를 직접 반환하는 방법이 전부였다. 코드를 통해 살펴보자
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);
clearDevice(handle);
} else {
logger.log("Device suspended .....");
}
} else {
logger.log("Invalid ........");
}
....
}위의 코드처럼 직접 오류 플래그를 만들고 직접 반환해주는 방법은 코드가 복잡해진다. 오류를 한 번에 처리하는 것이 아닌 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 또한 이렇게 반복되게 오류 처리를 하다 보면 잊어버리기도 쉽다. 그래서 예외가 발생하면 예외를 던져 예외처리를 한 번에 해주는 것이 가장 낫다. 아래는 예외를 던지는 코드이다.
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 ......");
....
}
...
}예외를 던지고 한 번에 처리해주는 것만으로도 코드가 많이 깨끗해졌다. 단순히 보기 좋아진 것뿐만 아니라 sendShutDown()에서 오류를 처리하고 tryToShutDown()에서 디바이스를 종료하여 뒤섞인 두 개념이 분리되어 코드의 품질도 더 나아졌다.
Try-Catch-Finally 문부터 작성하라
Try-catch-finlly 문에서 try블록에 들어가는 코드를 실행하면 어느 시점에서든지 실행이 중단된 후 catch문으로 넘어갈 수 있다. 어떤 면에서 try 블록은 트랜잭션과도 비슷하다. try블록에서 어떤 일이 생겨도 catch 블록에서 대응하여 프로그램 상태를 일관성 있게 유지해야 한다. 그러므로 예외가 발생할 코드를 짤 때에는 try-catch-finally 문부터 작성하는 것이 좋다. try 블록에서 무슨 일이 생기던 호출자가 원하는 응답을 정의하기가 쉬워진다.
그렇다면 어떻게 해야 잘 사용할 수 있을지 아래의 코드를 통해 더 자세히 알아보자.
// 파일이 없다면 예외를 던지는지 확인하는 단위 테스트케이스
@Test(expected = StorageException.class)
public void retrieveSectionShouldThrowOmInvalidFileName(){
sectionStore.retrieveSection("invalid - file");
}첫 번째로 예외를 던지는지 확인하는 테스트 케이스를 작성하자. try 블록에서 코드가 실패한다면 catch 블록은 적절한 예외를 던져야 한다. 적절한 예외를 던지는지 알기 위해서는 강제로 예외를 던지는 테스트 케이스를 통과시키는 것이 가장 좋은 방법이기 때문이다.
// 파일이 없을시에 예외를 던지는 코드
public List<RecordedGrip> retrieveSection(String sectionName) {
try{
fileInputStream stream = new FileInputStream(sectionName);
} catch (Exception e){
throw new StorageException("retrieval error, e);
}
return new ArrayList<RecerdedGrip>();
}두 번째로 Exception 예외를 던져 테스트가 성공하는지 확인한다.
// 예외의 범위를 좁혀 적절한 예외를 던져주는 코드
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<RecerdedGrip>();
}세 번째로 테스트가 성공했다면 리펙토링을 통해 예외의 범위를 좁혀주자. 무슨 상황이던지 Exception 예외 하나만을 던진다면 무슨 에러가 발생했는지 자세히 알 수 없을 뿐 아니라 의미 없는 예외 코드가 될 것이다. 범위를 좁혀 FileInputStream 생성자가 던지는 FileNotFoundException을 잡아준다.
위와 같이 예외를 일으키는 테스트 케이스를 작성한 후 통과하는 테스트 케이스를 작성하는 것을 권장한다. 그래야 자연스럽게 try블록의 트랜잭션 범위부터 구현하게 되기 때문이다.
미확인 unchecked 예외를 사용하라
먼저 예외와 에러의 차이 그리고 확인된 예외와 미확인된 예외가 무엇인지 알아보자.
예외와 에러 그리고 확인된 예외와 미확인 예외
[예외 (Exception)]
예외란 프로그램 내에서 발생하는 예외상황으로 프로그램 실행 중에 참조된 값이 잘못된 경우 등... 주로 배열의 크기에서 벗어난 인덱스에 접근하거나, 없는 파일을 열 때 발생한다. 자바에서 예외는 개발자가 직접 처리할 수 있기 때문에 예외 상황을 미리 예측하여 핸들링할 수 있다.
[에러 (Error)]
에러란 시스템에서 발생하는 발생하는 에러 즉, JVM 내에서 발생하는 에러로 프로그램 내에서 개발자가 처리가 불가능하다. 예시로는 OutOfMemoryError, ThreadDeath 등이 있다.
예외는 "확인된 예외(Checked Exception)"와 "미확인 예외(Unchecked Exception)" 두 가지로 구분된다. 확인된 예외의 경우는 컴파일 단계에서 에러가 발생하기 때문에 무조건 처리해줘야 하지만, 미확인 예외는 개발자의 판단하에 처리하기 때문에 신경을 더 많이 써줘야 한다.
[확인된 예외(Checked Exception)]
- 잘못된 코드가 아닌 잘못된 상황에서 발생하는 예외이다.
- 파일 열기와 같이 정확히 코드를 구현했음에도 불구하고 외부 환경(파일이 없는 상황 등)에 따라 발생이 가능하다.
- 명시적인 예외 처리를 강제하기 때문에 try~catch로 예외를 잡거나 throws로 호출한 메서드에게 예외를 던져 예외처리를 구현해줘야 한다. 구현하지 않을 시 컴파일 에러가 발생한다.(컴파일 시에 확인해서 확인된 예외이다.)
- RuntimeException 이외의 예외들이다.
[미확인 예외(Unchecked Exception)]
- 런타임 시 잘못 구현된 코드로 인해 발생하는 예외이다.
- 컴파일 에러가 나지 않지만 적절한 예외처리가 없을 경우 프로그램이 강제 종료된다.
- 컴파일 시 확인하지 않고, 명시적인 예외처리를 강제하지 않기 때문에 Unchecked Exception이라 한다.
- RuntimeException에 포함된 예외들이다.
[왜 확인된 예외와 미확인 예외로 나뉘었을까?]
메서드를 호출하는 쪽은 그 메서드가 어떤 예외를 발생시킬지 알아야 한다. 따라서 자바는 checked Exception을 통해 해당 메서드가 발생시킬 예외를 강제로 처리하도록 하고 있다.
그렇다면 Runtime Exception 즉, 미확인 예외는 왜 강제로 처리하지 않을까? 미확인 예외는 잘못 구현된 코드로 인해 발생하는 예외이기 때문이다. 어디서나 빈번하게 발생할 수 있기 때문에 모든 Runtime Exception을 메서드에 명시하도록 강제하는 것은 코드를 지저분하게 만들 뿐만 아니라 프로그램의 명확성을 떨어트릴 수 있다.
슬슬 본론으로 들어가 보자.
미확인 예외를 사용하라!
자바 첫 버전이 확인된 예외를 선보였던 당시에는 확인된 예외를 모두 멋진 아이디어라고 여겼다. 메서드를 선언할 때는 메서드가 반환할 예외를 모두 열거했고, 예외는 메서드 유형의 일부였다. 또한 코드가 메서드를 사용하는 방식이 메서드 선언과 일치하지 않으면 컴파일을 하지 못했다고 한다.
확인된 예외는 실제로도 몇 가지 장점을 제공한다. 그러나 지금에 와서는 안정적인 소프트웨어를 제작하는 요소로 확인된 예외가 반드시 필요하지는 않다는 사실이 분명해졌다. 앞서 잘 사용되고 있는 c#, c++, 파이썬, 루비 언어들은 확인된 예외를 지원하지 않는다. 그럼에도 불구하고 안정적인 소프트웨어를 개발하는데 무리가 없다. 그러므로 우리는 확인된 오류가 치르는 비용에 상응하는 이익을 제공하는지 잘 따져봐야 한다.
우리가 확인된 예외를 사용함으로써 치르는 비용은 OCP(개방-폐쇄 원칙, Open Closed principle)를 위반하는 것이다.
위키백과에 정의된 OCP에 대한 내용이다.
소프트웨어 개발 작업에 이용된 많은 모듈 중에 하나에 수정을 가할 때 그 모듈을 이용하는 다른 모듈을 줄줄이 고쳐야 한다면, 이와 같은 프로그램은 수정하기가 어렵다. 개방-폐쇄 원칙은 시스템의 구조를 올바르게 재조직(리팩터링) 하여 나중에 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않도록 하는 것이다. 개방-폐쇄 원칙이 잘 적용되면, 기능을 추가하거나 변경해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도, 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능하다.
메서드에서 확인된 예외를 던졌는데 catch 블록이 몇 단계 위에 있다고 한다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다. 즉, 하나의 모듈에서 예외를 던질 때 해당 모듈을 이용하는 다른 모듈들에 줄줄이 예외를 정의해야 하는 것이다. 코드를 통해 살펴보자!
public FileManager getFile(FileRequestDto file) {
try{
example(file);
}catch (FileNotFoundException e){
logger.log(e);
}
}
public static void example(FileRequestDto file) throws FileNotFoundException {
fileExample(file.getFileName());
....
}
public static void fileExample(String fileName) throws FileNotFoundException {
FileInputStream stream = new FileInputStream(fileName);
....
}
fileExample 메서드에서 던진 예외를 example 메서드에서 알고 있는 걸 볼 수 있다. getFile 즉, 해당 예외가 처리되기까지 중간과정에 속해있는 메서드들은 모두 예외를 알고 있어야 한다는 문제점을 확인할 수 있다.
작은 시스템에서는 괜찮다 생각할 수 있지만, 대규모 시스템에서 일어나는 호출 방식을 생각해보자. 최상위 함수가 아래 함수를 호출한다. 아래 함수는 그 아래 함수를 호출한다. 단계를 내려갈수록 호출하는 함수가 늘어난다. 만약 이때에 최하위 함수를 변경해 확인된 예외를 던진다면 함수는 선언부에 throws 절을 추가해야 한다. 이렇게 된다면 해당 함수를 호출하는 모든 함수가 throws 절을 추가해야 하고 최하위 함수부터 최상위 함수까지 연쇄적인 수정이 일어난다. throws 경로에 위치하는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다.
물론 최하위 함수에서 바로 예외를 처리하는 방법도 있다. 그러나 우리는 "오류코드보다 예외를 사용하라"에서 예외를 던져 오류처리를 한 번에 해주는 것이 가장 낫다는 것과 무언가를 처리하는 메서드와 오류를 처리하는 메서드가 분리되는 것이 낫다는 것을 알게 되었다. 그렇기에 예외를 던져서 처리하는데 오류를 원거리에서 처리하기 위해 예외를 사용한다는 사실을 감안한다면 이처럼 확인된 예외가 캡슐화를 깨버리는 현상은 유감스럽다.
확인된 예외가 유용할 때도 있다. 중요한 라이브러리를 작성한다면 모든 예외를 잡아야 한다. 그러나 일반적인 애플리케이션은 의존성이라는 비용이 이익보다 크다.
예외에 의미를 제공하라
예외를 던질 때에는 해당 상황에 대해서 자세히 남겨주는 것이 좋다. 오류가 발생한 원인과 위치를 찾기 쉬워지기 때문이다. 자바는 모든 예외에 호출 스택을 제공하지만 호출 스택만으로는 원인을 찾아내기 힘들기에 오류 메시지에 자세한 정보를 담아 예외와 함께 던져주는 것이 좋다. 만약 애플리케이션이 로그를 남긴다면 catch 블록에서 오류를 파악하기 쉽도록 충분한 정보를 남겨주는 것이 좋다.
호출자를 고려해 예외 클래스를 정의하라
오류를 분류하는 방법은 수없이 많다. 그러나 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.
아래의 예제 코드는 오류를 형편없이 분류한 사례이다. 외부 라이브러리를 호출하는 try-catch-final 문을 포함한 코드로, 외부 라이브러리가 던질 예외를 모두 잡아내는 코드이다.
// 라이브러리가 던질 예외를 모두 잡아낸다.
ACMEPort port = new ACMEPort(12);
try{
port.open();
} catch (DeviceResponseException e){
reportPortError(e);
logger....
} catch (ATM1212UnlockedException e) {
reportPortError(e);
logger....
} catch (GMXError e){
reportPortError(e);
logger....
} finally{
.....
}
위 코드의 경우에 예외를 대응하는 방식 즉, catch 블록의 로직이 예외 유형과는 다르게 동일하다. 그러므로 모든 예외를 잡아내는 것은 의미가 없다. 위와 같은 경우는 더욱 간결하게 고치기 쉽다. 호출하는 라이브러리 API를 감싸서 예외 유형을 하나만 반환해주면 된다. 아래 코드를 통해 살펴보자.
LocalPort port = new LocalPort(12);
try{
port.open();
} catch (PortDeviceFilure e){
reportError(e);
logger....
} finally {
...
}
// ACMEPort 클래스가 던지는 예외를 잡아 변환하는 감싸기 클래스
public class LocalPort{
private ACMEPort innerPort;
public LocalPort(int portNumber){
innerPort = new ACMEPort(portNumber);
}
public void open(){
try{
innerPort.open();
} catch (DeviceResponseException e){
throws new PortDeviceFailure(e);
} catch (ATM1212UnlockedException e){
throws new PortDeviceFailure(e);
} catch (GMXError e) {
throws new PortDeviceFailure(e);
}
}
....
}LocalPort 클래스처럼 ACMEPort를 감싸는 클래스는 매우 유용하다. 실제로 외부 API를 사용할 때는 감싸기 기법을 사용하면 많은 장점들을 가져다준다.
- 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에 의존성이 크게 줄어든다.
- 나중에 다른 라이브러리로 갈아타더라도 비용이 적다. 하나의 예외만 반환하면 되기 때문이다.
- 감싸기 클래스에 외부 API를 호출하는 대신 테스트 코드를 넣어주는 방법으로 프로그램을 테스트하기 쉬워진다.
- 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다. 프로그램이 사용하기 편리한 API를 정의하여 사용하면 그만이다.
감싸기 클래스를 하나 만들어 port 디바이스 실패를 표현하는 예외 유형 하나를 정의했을 뿐인데 코드가 깔끔해진 것과 동시에 많은 장점들을 얻었다.
정상 흐름을 정의하라
앞서 나온 모든 충고와 지침들을 충실히 따라간다면 비즈니스 논리와 오류 처리가 잘 분리된 코드가 나오게 된다. 그러나 외부 API를 감싸 독자적인 예외를 던져 중단한 뒤 호출한 코드에서 처리를 정의해 중단된 계산을 처리하는 것이 적합하지 않은 경우도 있다. 이러한 경우에는 특수 사례 패턴(SPECIAL CASE PATTERN)을 적용해 개선할 수 있다. 코드를 통해 특수 사례 패턴을 알아보자.
특수 사례 패턴(SPECIAL CASE PATTERN)
반환할 값이 없을 때 예외를 던지는 것이 아니라 기본값을 반환하는 패턴
아래 코드는 비용을 청구하는 애플리케이션에서 총계를 계산하는 코드이다.
try{
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
mTotal += expenses.getTotal();
} catch (MealExpensesNotFound e){
mTotal += getMealPerDiem();
}식비를 비용으로 청구했다면 직원이 청구한 식비를 총계에 더한다. 식비를 비용으로 청구하지 않았다면 catch 블록에서 일일 기본 식비를 총계에 더한다. 그런데 위와 같은 코드는 예외처리가 논리를 따라가기 어렵게 만든다. 이러한 특수 상황을 처리할 필요가 없어진다면 더 깔끔한 코드가 될 것이다.
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
mTotal += expenses.getTotal();
public class PerDiemMealExpenses implements MealExpenses {
private static final int MEAL_EXPENSES_DEFAULT = 7000;
public int getTotal() {
// 기본값으로 일일 기본 식비를 반환해준다.
return MEAL_EXPENSES_DEFAULT;
}
}ExpenseReportDAO를 고쳐 항상 MealExpense 객체를 반환하게 한다. 만약 청구한 식비가 없다면 일일 기본 식비를 반환하는 MealExpense 객체를 반환하는 방법이다. 위와 같은 방법을 특수 사례 패턴이라고 부른다. 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식이다.
위와 같은 방법으로 처리한다면 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하기 때문에 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.
null을 반환하지 마라
우리가 오류를 유발하는 습관 중 하나는 null을 반환하는 것이다. 평소 if문을 통해 null을 반환하는 코드를 봐왔다면 나쁘지 않다고 느낄 수도 있다. 그러나 어디선가 하나라도 null 확인을 빼먹는다면 NullPointerException이 발생하며 애플리케이션이 통제 불능에 빠질 가능성이 생긴다.
그렇기에 메서드에서 null을 반환하고 싶은 유혹이 든다면 예외를 던지거나 특수 사례 패턴을 사용하는 것을 권장한다. 또한 사용하는 외부 API가 null을 반환할 때도 마찬가지다. 감싸기 클래스와 특수 사례 패턴으로 처리해주길 권장한다. 대부분에 경우에는 특수 사례 패턴을 사용하는 것이 손쉬운 해결책이라고 한다. 코드를 통해 살펴보자.
List<Employee> employees = getEmployees();
if (employees != null){
for (Employee e : employees) {
totalPay += e.getPay();
}
}위의 코드는 null을 반환한다. 하지만 반드시 null을 반환할 필요가 없다. getEmployees()를 변경해 빈 리스트를 반환한다면 코드가 훨씬 깔끔해질 것이다. 다행히도 자바에는 Collections.empltyList() 읽기 전용 빈 리스트를 반환해줄 수 있다.
List<Employee> employees = getEmployees();
for (Employee e : employees) {
totalPay += e.getPay();
}
// 직원이 없다면 빈 리스트를 반환
public List<Employee> getEmployees(){
if (.. 직원이 없다면 ..) {
return Collections.emptyList();
}
}위와 같이 코드를 변경한다면 코드도 깔끔해질 뿐만 아니라 NullPointerException이 발생할 가능성도 줄어든다.
null을 전달하지 마라
메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. 보통 정상적인 인수로 null을 기대하는 API는 거의 없을 것이다. 정말 인수값으로 null을 기대하는 게 아니라면 메서드로 null을 전달하는 행동은 해서는 안된다.
만약 인자 값으로 null이 전달될 가능성이 있다면 인수로 들어오는 값들에 대해 항상 null 체크를 해줘야 할 것이다. 분명 코드가 아주 지저분해질 것이고 처리를 제대로 해주지 못한다면 NullPointerException이 발생할 것이다. 대안으로 assert 문을 사용하는 방법이 있지만 이것도 코드를 아주 잘 정리하는 방법일 뿐 문제를 해결하지는 못한다.
대다수에 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 그렇기에 애초에 null을 넘기지 못하도록 금지하는 정책이 가장 합리적이다. 즉, null이 인수로 넘어오는 것부터 코드에 문제가 있다는 말이다. 이러한 정책을 확실히 하여 부주의한 실수를 저지를 확률을 낮추자!
마무리
깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 오류 처리를 프로그램 논리와 분리해서 코드를 작성하면 오류 처리를 프로그램 논리와 분리하여 독립적인 추론이 가능해지고 코드 유지보수성도 크게 높아진다.
나는 이번 제7장 예외 처리를 읽으면서 많은 생각이 들었다. 내게 오류처리란 if문과 해당 메서드에서 바로 try-catch-finally문을 사용하는 것이 전부였기 때문이다. 예외를 던져 한 곳에서 처리하여 오류처리와 서비스 로직의 개념을 분리할 생각도 해보지 못했고, null 대신 빈 리스트를 반환할 생각도 못해봤다. if문으로 null을 처리하는 것을 당연하게 여기고 있었다.
인수로 null을 전달하는 것도 마찬가지다. 당연히 null을 전달하면 안 되겠지만 생각해보지는 못했던 문제이다. 내가 자연스럽게 넘기고 있던 인수들이 null을 반환할 가능성에 대해 생각하지 못했었다. 여러모로 많은 것을 배우게 됐다.
가장 기억해야 할 것이 무엇이냐 고르라 하면 하나를 딱 집어 고를 수 없을 정도로 많은 도움이 되었다. 아래는 내가 꼭 기억하며 적용해 나가야 할 내용들을 요약해두었다.
- 오류를 분류하는 방법은 많다 그러나 핵심은 오류를 잡아내는 방법이다. 외부 API에 대해서는 감싸기 클래스를 만들어 외부 API와의 의존성을 낮추고 예외 및 여러 상황들에 대응하자.
- 특수 사례 패턴을 사용하여 null을 방지하고 프로그램의 논리를 간단하게 만들자.
- 인수에 null이 전달되지 않도록 항상 주의하자.
- 예외 처리 시 호출 스택만을 남기기보다는 에러 로그를 통해 에러를 파악할만한 충분한 정보를 넘겨주자.
- 오류 코드보다 예외를 사용하고 실패하는 테스트 케이스를 꼭 작성하자.
'Read Book > CleanCode' 카테고리의 다른 글
| CleanCode 9장 단위 테스트 (0) | 2022.11.16 |
|---|---|
| CleanCode 8장 경계 (0) | 2022.11.09 |
| CleanCode 6장 객체와 자료구조 (0) | 2022.10.05 |
| CleanCode 5장 형식 맞추기 (0) | 2022.09.24 |
| CleanCode 4장 주석 (3) | 2022.09.19 |
