Clean code 7장 오류 처리

[jordan-choi]

깨끗한 코드와 오류 처리의 연관성

여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 어렵다면 깨끗한 코드라 부르기 어렵다.

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

• 예외를 지원하지 않는 언어는 오류를 처리하는 방법이 제한적이다:

  • 오류 플래그를 설정하거나
  • 호출자에게 오류 코드를 반환하거나

  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("Invalid 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-finally 문은 [try 블록]과 [[catch 블록] 또는 [finally 블록] 또는 [catch 블록, finally 블록 둘 다]] 로 이루어진다.

  • try…catch
  • try…finally
  • try…catch…finally

  try {
  	// executed first
  } catch (error) {
  	// if `try` block throws an exception,
  	// the code in the `catch` block will be excuted.
  } finally {
  	// always be executed 
  	// before control flow exits the entire construct.
  }

• try-catch-finally 문은 예외 처리의 범위를 정할 수 있다.

  • try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다.
  • try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.

• 예외가 발생할 코드를 짤 때 try-catch-finally 문으로 시작하면, try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다.

  • 예외가 발생하는 케이스를 먼저 정의하고 테스트한다.

  public List<RecordedGrip> retrieveSection(String sectionName) {
  	try {
  		FileInputStream stream = new FileInputStream(sectionName);
  		// ...
  		stream.close();
  	} catch (Exception e) {
  		// 예외 유형을 좁혀서 에러를 잡는다.
  		throw new StorageException("retrieval error", e);
  	} 
  	return new ArrayList<RecordedGrip>();
  }

미확인(unchecked) 예외를 사용하라

• 확인된(checked) 예외가 좋을까?
  • 확인된 예외는 [OCP(Open Closed Principle)](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)를 위반한다.
    • 확인된 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다.
    • 하위 함수에서 새로운 확인된 오류를 던진다면, 바로 위 함수부터 최상위 함수까지 모두 확인된 오류에 대한 예외 처리를 해야 한다. —> 연쇄적인 수정이 필요하다.
    • 상위 함수들이 모두 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다.
    • 모듈과 관련된 코드가 전혀 바뀌지 않았더라도 모듈을 다시 빌드한 다음 배포해야 한다.
• 확인된 예외가 치르는 비용에 상응하는 이익을 제공하는지 따져봐야 한다.
  • 아주 중요한 라이브러리르 작성한다면 모든 예외를 잡아야 한다.
  • 일반적으로는 의존성이라는 비용이 이익보다 크다.

예외에 의미를 제공하라

예외를 던질 때 오류 메세지에 전후 상황을 덧붙여 오류가 발생한 원인과 위치를 찾기 쉽게 하자.

• 실패한 연산 이름, 실패 유형 등.

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

• 오류를 분류하는 방법은 수없이 많다.
  • 오류가 발생한 위치 (e.g., 오류가 발생한 컴포넌트)
  • 오류 유형 (e.g., 디바이스 실패, 네트워크 실패, 프로그래밍 오류)
• 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.

  • 아래 코드는 오류를 일으킨 원인과 무관하게 모든 오류를 동일하게 나열했다.

    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", e);
    } finally {
    	...
    }

  • 위 코드를 wrapper 클래스를 이용해 아래와 같이 개선할 수 있다.

    LocalPort port = new LocalPort(12);
    
    try {
    	port.open();
    } catch (PortDeviceFailure e) {
    	reportError(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 (ATM1212UnlockedException e) {
    			throw new PortDeviceFailure(e);
    		} catch (GMXError e) {
    			throw new PortDeviceFailure(e);
    		}
    	}
    }

    • 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.
      • 나중에 다른 라이브러리로 갈아타도 비용이 좋다.
      • 테스트하기도 쉽다: wrapper 클래스에서 외부 API를 호출하는 대신 테스트 코드를 넣어주는 방법 이용.
    • 의존성이 줄어들면 특정 업체가 API를 설계한 방식에 관계 없이 프로그램이 사용하기 편리한 API를 정의하면 된다.

정상 흐름을 정의하라

• 외부 API를 감싸 독자적인 예외를 던지고, 중단된 계산을 처리하는 코드를 넣는 방식이 적합하지 않을 때도 있다.

• 아래 코드는 예외가 논리를 따라가기 어렵게 만든다.

  try {
  	MealExpenses expenses = expenseResportDAO.getMeals(employee.getId());
  	m_total += expenses.getTotal();
  } catch (MealExpensesNotFound e) {
  	m_total += getMealPerDiem();
  }

• 특수 상황을 처리할 필요가 없게 한다면? ([특수 사례 패턴(Specital case pattern)](https://martinfowler.com/eaaCatalog/specialCase.html))

  • 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식. 클래스나 객체가 예외적인 상황을 캡슐화해서 처리한다.
  • 클라이언트가 예외적인 상황을 처리할 필요가 없어진다.

  MealExpenses expenses = expenseResportDAO.getMeals(employee.getId());
  m_total += expenses.getTotal();

  public class PerDiemMealExpenses implements MealExpenses {
  	public int getTotal() {
  		// 기본값으로 일일 기본 식비를 반환한다. 
  	}
  }

오류를 유발하는 행위

1. null을 반환하지 마라. 예외를 던지거나 특수 사례 객체를 반환해라.

   • null을 반환하는 코드는 호출자에게 문제를 떠넘긴다.
   • null 확인이 누락된 문제? ❌. null 확인이 너무 많아 문제 ⭕️.

   // ❌ BAD
   // 쉴 새 없이 null을 반환하는 냄새나는 코드
   public void registerItem(Item item) {
   	if(item != null) {
   		ItemRegistry registry = peristentStore.getItemRegistry();
   		if(registry != null) {
   			Item existing = registry.getItem(item.getID());
   			if(existing != null) {
   				if(existing.getBillingPeriod().hasRetailowner()) {
   					existing.register(item);
   				}
   			}
   		}
   	}
   }

2. null을 전달하지 마라. 1보다 더 나쁘다.

   • 정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피한다.
   • 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다.
   • 인수로 null을 넘기지 못하도록 금지하는 정책을 따르면 부주의한 실수를 저지를 확률도 작아진다.