[Clean Coding] 7. Error Handling

🔻 주요 내용 : Wrapping Class, special case pattern

🖋️ Error Handling

• Error : 결함, 실패 혹은 프로그램의 이상으로 인해 예상치 못하거나 틀린 결과가 생성되거나 의도하지 않은 방식으로 작동하게 되는 것
• Error Handling : 예상치못한 에러로부터 회복하는 것
  • ex. request user intervention, recover on its own, shut down the system

프로그래머는 잘못될 것을 대비하여서 프로그램이 원래 작동되어야 하는 방식으로 작동되도록 설계하는 것에 책임이 있다

많은 코드는 에러 핸들링에 지배를 받아 여기저기 흩어진 에러 핸들링으로 인해 코드가 어떻게 작동하는지 파악하기가 어렵다

에러 핸들링은 중요하지만, 만약 로직을 불명확하게 만든다면 틀린 것이다. 따라서 어떻게 에러 핸들링을 잘 할 수 있는지를 살펴볼 것이다!

📌 [잘못된 방법] ERROR FLAG

• error flag을 설정하거나, error code를 반환하여 호출자가 확인할 수 있도록 하는 방법

public class DeviceController {
	...
    public void sendShutDown() {
    	DeviceHandle handle = getHandle(DEV1);
        //Check the state of the device
        if (handle != DeviceHandle.INVALID) {
        	//Save the device status to the record field
            DeviceRecord record = retrieveDeviceRecord(handle);
            // if not suspended, shut down
            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());
        }
    }
    ....
}

두 번째 if문 안의 세개의 메소드가 main logic!
DeviceRecord record = retrieveDevice(handle) 에서 값을 넣어줬기 때문에 if가 필요한 것이고, 잘못된 것을 넣었을 때를 보여주는 코드이다

문제점

• 호출자에게 불필요한 복잡성을 유발 : 호출 코드의 로직이 에러 처리 코드로 인해 가려져 혼란스러워질 수 있다
• 에러 확인의 의무 : 호출자는 호출 직후에 반드시 에러를 확인해야 하지만, 이를 잊어버리기 쉽다

📌 [옳은 방법] Throwing Exception

• 에러가 발생했을 때 예외를 던지는 것(throw an exception)이 더 나은 접근
  • 호출 코드가 더 간결해진다
  • 로직이 에러 처리 코드로 가려지지 않는다

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(DeivceID id) {
    	...
        throw new DeivceShutDownError("Invalid handle for: " + id.toString());
        ...
    }
    ...
}

• DeviceShutDownError에 안에 적힌 내용을 try-catch문에서 하나씩 처리해주면 지저분해질 수 있기 때문에 method를 생성해서 그 메서드에서 한 번에 다 처리하도록 구현한 코드이다
• 마지막 throw new DeviceShutDownError~ 부분도 원래는 return ~ 이었지만, 간결하게 에러를 처리하기 위해 위 코드와 같이 작성되었다

이로써 코드를 독립적으로 보고 이해할 수 있게 된다

결론! return 코드보다는 exceptions을 사용하라!

🔻 try-catch-(finally)를 먼저 작성하고 시작할 것!

try { 
	//do something
} catch (XException e) {
	//handle XException
} catch (YException e) {
	//handle YException
} finally {
	// clean up
}

• try blocks
• catch blocks

예외처리를 할 수 있는 경우에, try-catch-finally을 먼저 선언하고 시작하는 연습을 하는 것이 좋다

✏️ [STEP 1] : the first draft

public List<RecordedGrip> retrieveSection(String sectionName) {
	//dummy return until we have a real implemenation
    return new ArrayList<RecordedGrip>();
}

1. 함수의 입력 정하기 (retrieveSection)
2. 함수의 출력 정하기 (String sectionName)
3. return value (return 문)

compile은 되어야 하니 우선 빈 array를 넣는 것!

✏️ [STEP 2] : try-catch-finally을 먼저 작성하기

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>();
}

여기서 new~ 를 통해 객체를 만들어주었는데, 객체 사용 후엔 날려주는 게 좋다 (open -> close해야)

이처럼 뼈대부터 잡고 채워나가는 것!

✏️ [STEP 3] : 리팩토링을 하여 예외의 종류를 좁혀나갈 것

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>();
}

• stream.close()부터 작성하고 빈 곳을 채우는 것!

✏️ [STEP 4] : 나머지 로직을 채워나갈 것

public List<RecordedGrip> retrieveSection(String sectionName) {
	try {
    	FileInputStream stream = new FileInputStream(sectionName)
        //나머지 로직 여기에
        stream.close();
    } catch (FileNotFoundException e) {
    	throw new StorageException("retrieval error", e);
    }
    return ...;
}

📌 예외처리를 내용과 함께 제공하기

• 각각의 예외는 충분한 내용을 제공해야 한다
• debugging이 편하도록 생성해야 한다
  • 어디서 발생했는지
  • 왜 발생했는지

실패한 해당 operation과 실패 종류를 언급한다
catch문에 이를 작성하여 에러를 log 할 수 있다

예시

public static void main(String[] args) {
	Scanner scanner = new Scanner(System.in); //#1
    int firstNumber, secondNumber, result;
    
    firstNumber = scanner.nextInt();
    secondNumber = scanner.nextInt();
    scanner.close(); //#1
    try{
    	result = divideInt(firstNumber, secondNumber);
    } catch (DivideByZeroException e) {
    	System.out.println(e.getMessage());
    }
}

public static int divideInt(int dividend, int divisor) {
	if (divisor == 0)
    	throw new DivideByZeroException("divideInt() : divisor cannot be 0");
    retrun dividend / divisor;
}

• #1 : 세트로 박아놓고 시작하기!!
• DivideByZeroException("divideInt() : divisor cannot be 0") 에서
  • divideInt() : 어디
  • divisor cannot be 0 : 왜

❗️try 문에서 divideInt를 사용해야 하는 이유

1. step down rule을 따르기 위함
2. 함수로 떼어놓지 않으면 testable 하지 않기 때문. Unit Test가 가능해야 하므로 분리!

📌 호출자의 필요에 따라 예외 클래스를 정의할 것

에러를 분류하는 방법에는 여러 방법이 존재한다

• 소스로 (ex. 어떤 컴포넌트인지)
• 종류로 (ex. 장치 결함, 네트워크 오류)
• ...

이렇게 너무 다양하게 던지면 받는 쪽에서 괴로워지고, 코드도 지저분해진다

예외 클래스를 정의할 때는 그들이 어떻게 잡힐 것인지를 가장 중요하게 고려해야 한다. 즉, 호출자에 의해 어떻게 핸들링 될 것인지를 말하는 것

기본적으로는 분리하지 않고 같이 처리하고,
exception끼리 다르게 처리하길 바랄 때 분리를 할 것!

📍 Bad example

• 여기서 ACMEPort는 third-party 라이브러리로, 여러 종류의 예외를 던질 수 있다
• 코드에서는 모든 가능한 예외를 처리하려고 시도하며, 다음과 같은 문제가 발생할 수 있다
  • 중복 코드 : 모든 catch 블록에서 비슷한 작업 (예: 에러 기록)을 반복
  • 유지보수 어려움 : 새로운 예외가 추가되면 더 많은 catch 블록을 작성해야함

ACMEPort port = new ACMEPort(12);

try {
    port.open();
} catch (DeviceResponseException e) {
    reportPortError(e);
    logger.log("Device response exception", e);
} catch (ATM121UnlockedException e) {
    reportPortError(e);
    logger.log("Unlock exception", e);
} catch (GMXError e) {
    reportPortError(e);
    logger.log("Device response exception");
}

모든 예외에서 reportPortError(e)와 로그 기록(logger.log)을 반복 - 동일한 패턴이 반복되므로 코드가 불필요하게 길어짐.

📍 Better example

• 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; //1
    public LocalPort(int portNumber) {
    	innerPort =new ACMEPort(portNumber); //2
    }
    
    public void open() {
    	try {
        	innerPort.open(); //3
        } catch (DeviceResponseException e) {
        	throw new PortDeviceFailure(e); //4
        } catch (ATM121UnlockedException e) {
        	throw new PortDeviceFailure(e);
        } catch (GMXError e) {
        	throw new PortDeviceFailure(e);
        }
    }
}

1. 하나로만 통일하고 싶다면 걔를 감싸는 wrapper class를 만든다!
2. 객체를 생성해준다
3. 세 가지 타입을 던졌지만
4. PortDeviceFailure(e)로 통일시켜준 것!

🖋️ Wrapping Class

• third-party API를 wrapping 하는 것은 좋은 연습이다!

🔻 장점

• 종속성을 줄인다
  • 특정 서드파티 라이브러리에서 다른 라이브러리로 전환할 때 코드 수정 비용이 적음
• 유연한 API 설계
  • 특정 third-party 제공자의 API 설계 선택에 구속되지 않는다
  • 자신이 사용하기 편리한 API를 정의하여 활용 가능하다

예를 들어보자

class XCalc {
	int plus(int a, int b)...
    int minus(int a, int b)...
}

여기서 만약 이름을 add, subtract로 수정하고 싶다면

class MyCalc {
	XCalc innerCalc = new XCalc();
    int add(int a, int b) {
    	return innerCalc.plus(a, b);
    }
    
    int subtract(int a, int b) {
    	return innerCalc.minus(a, b);
    }
}

Define the Normal Flow

위 코드를 보면

• normal case : 식비가 지불된 경우를 normal case로 본것
• special case : 식비를 지불하지 않았을 경우 직원들은 그날에 대한 식비 일당을 받음

special case는 에러는 아니며, 여기서는 exception으로 처리한 것이다

Problem) try-catch문 자체가 코드가 지저분해진 것
Solution) 자식 객체를 만들어서 같은 메소드명으로 처리한다

class A {
	void f(){..}
}

class B extends A {
	void f(){..}
}

class C extends A {
	void f(){..}
}

A a = new A();
a.f(); //1

a = new B();
//overriding
a.f(); //2

a = new C();
a.f(); //3

1. A의 f가 호출된다
2. B의 f가 호출된다. 상속을 받았지만 overriding하여 내꺼로 덮어치운 것
3. C의 f가 호출된다

이처럼 Special Case Pattern을 사용함으로써, 스페셜 케이스가 코드의 복잡성을 높이지 못하게 하는 것이다

• ExpenseReportDAO.getMeals()를 수정하여, 항상 MealExpense 객체를 반환하도록 한다
  • 더 이상 MealExpensesNotFound를 던지지 않아도 된다
• 만약 식비 지불이 없다면, PerDiemMealExpenses 객체를 반환할 것이다
  • PerDiemMealExpenses : MealExpenses의 subclass

PerDiemMealExpenses라는 클래스를 생성하여 MealExpenses를 확장

public class PerDiemMealExpenses extends MealExpenses {
	public int getTotal() {
    	//return the per diem default
    }
}

• getTotal() 메서드를 구현하여 일당(per diem) 기본값을 반환한다

결과

• 일당이 있는 경우 : MealExpenses.getTotal()이 호출
• 일당이 없는 경우 : PerDiemMealExpenses.getTotal()이 호출

MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
m_total += expenses.getTotal();

🖋️ Special Case Pattern

• special class를 핸들링 하기 위한 subclass를 만드는 것
• 예외를 던지는 것이 아니라 special case object를 반환하게 하는 방법이다
• 이로써, 예외 처리를 다루지 않아도 되고 special case 객체 내부에 동작을 캡슐화하여 코드의 간결성을 유지할 수 있다

MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
m_total += expenses.getTotal();

📌 Null 반환하지 않기

만약 메서드가 null을 반환하게 하면, 호출하는 사람마다 null check을 해야 한다

그러면 많은 널체크로 인해 코드가 불명확해질 수 있다
더불어, 널체크 하나를 놓치면 어플리케이션을 제어하기 어려워진다 - NullPointException 발생

public void registerItem(Item item) {
	if (item != null) {
    	ItemRegistery registery = persistentStore.getItemRegistery();
        if (registery != null) {
        	Item existing = registery.getItem(item.getID());
            if (existing.getBillingPeriod().hasRetailOwner()) {
            	existing.register(item);
            }
        }
    }
}

다음 코드는 너무 많은 널체크를 가지고 있다
널 체크를 하기 위해서는 if문이 필요하기에, 중첩된 if문이 발생한다

따라서 null을 반환하지 않도록 팀끼리 약속해야한다!

이런 경우, special cas object를 대신 반환하는 것을 고려해볼 수 있다!

예시

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

getEmployees()는 null을 리턴할 수 있다. 하지만 그래야만 하는가?

▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽▽

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

빈 리스트를 리턴하도록 하면 코드를 간결하게 만들 수 있다!

🔻 argument로도 Null을 주지 말 것

• Java는 Collections.emptyList()를 제공한다
• 이미 정의된 불변 리스트 (Immutable List)인 Collections.emptyList() 를 제공
• Null 대신 빈 리스트를 반환하여 NullPointerException 발생 가능성을 줄임

개선된 코드를 살펴보자

public List<Employee> getEmployees() {
    ...
    if (... there are employees ...) {
        return employees;
    } else if (... there are no employees ...) {
        return Collections.emptyList();
    }
}

NullPointerException 발생 가능성을 최소화하고, 코드 가독성 및 유지보수성을 개선할 수 있다

📌 Null Pass하지 않기

메서드에서 Null을 리턴하는 것도 나쁘지만, 메서드에게 null을 패스하는 것은 더 나쁘다

null을 주고 받기 시작하면 받는 쪽에서 할 수 있는게 많지 않다 -> if문으로 check해도 exception을 throw하는 것밖에 하지 못한다

아래와 같은 클래스가 있다고 해보자

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

어떤 사람이 매개변수로 null을 패스하면 어떻게 될까?

calculator.xProjection(null, new Point(12,13));

당연히 NullPointException을 받을 것이다

🔻 Null 전달 방지 방안

📍 새 예외 유형 정의하기

• Null 값이 전달될 경우를 처리하기 위해 새 예외 유형 (InvalidArgumentException)을 정의하고 이를 던진다

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

장단점

• NullPointerException보다 나은 선택일 수 있다
• 하지만, InvalidArguementException을 처리하기 위한 핸들러를 정의해야 한다
• 핸들러에서 어떤 처리를 해야할지 명확하지 않을 수 있다

📍 Assertion 사용

• Null 검사를 위해 Assertion을 추가한다

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이 전달되면 런타임 에러가 여전히 발생할 수 있다
• Assertion은 문제를 해결하는 것이 아니라 디버깅에 도움을 줄 뿐이다

assert문은 모든 테스트를 통과하면 출시할 땐 이 두 줄을 제거하고 출시한다! 일종의 bug detection으로 사용하는 것이기 때문!

결론

• 클린 코딩은 잘 읽혀야 되지만, 동시에 강건해야 한다
  • 강건하다는 말은, 에러처리도 잘 한다는 의미
• 강건한 코드는 우리의 메인 로직으로부터 에러 핸들링을 분리함으로써 만들 수 있다
  • 독립적으로 볼 수 있고
  • 독립적으로 이유를 부여할 수 있다