Update: Error.md / 호출자를 고려해 예외 클래스를 따로 정의하자 까지 추가.

cyw320712 · cyw320712 · commit 7bb858699af3 · 2022-08-10T17:52:19.000+09:00
diff --git a/src/7. error.md b/src/7. error.md
@@ -0,0 +1,283 @@
+# Error
+
+오류 처리는 프로그램에 반드시 필요한 요소 중 하나다. 뭔가 실패할 가능성은 늘 존재한다. 또한 그 잘못된 것을 바로 잡는 책임도 프로그래머에게 있다.
+
+클린 코드와 오류 처리 또한 연관이 있다. 여기저기 흩어진 오류 처리 코드들 때문에 실제 코드가 하는 일을 파악하기 어렵다면, 클린 코드라고 할 수 없다.
+
+이번 챕터에서는 오류 처리를 우아하고 고상하게 만드는 기법과 고려 사항들을 다룬다.
+<br><br>
+
+## 목차
+1. [오류 코드보단 예외를 사용하라](#예외)
+2. [Try-Catch-Finally 문부터 작성하라](#폼부터)
+3. [미확인 예외를 사용하라](#미확인)
+4. [예외에 의미를 제공하라](#의미)
+5. [호출자를 고려해 예외 클래스를 정의하라](#호출자)
+6. [정상 흐름을 정의하라](#정상)
+7. [null을 반환하지 마라](#null반환)
+8. [null을 전달하지 마라](#null전달)
+9. [결론](#결론)
+<br><br>
+
+## <div id="예외">오류 코드보단 예외를 사용하라 </div>
+
+대부분의 언어는 예외 처리를 지원한다. **오류 플래그나 코드를 반환하는 함수는 호출자로 하여금, 함수를 호출한 즉시 오류를 확인하도록 강제한다.** 또한 이 단계는 무의식적으로 넘어가기 쉽다. 때문에 오류가 발생하면 예외를 던지는 편이 낫다.
+
+예외를 던지도록 하면, 호출자 코드가 더 깔끔해진다. **오류 처리 코드와 비즈니스 로직이 뒤섞이지 않는다. (바꿔 말하면, 둘이 뒤섞이면 이해하기 힘든 코드가 된다.)** 즉, 각 개념을 독립적으로 살펴보고 이해할 수 있게 된다!
+
+**Bad:**
+```java
+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());
+        }
+    }
+}
+```
+
+**Good:**
+```java
+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());
+        ...
+    }
+    ...
+}
+```
+
+확실히 코드가 깔끔해지고, 메인 로직이 어떤 일을 하는지 한 눈에 파악하기 쉬워졌다. 디바이스를 종료하는 알고리즘과 오류 처리 알고리즘의 분리만으로도 가독성이 크게 좋아진다.
+
+<br><br>
+
+## <div id="폼부터">Try-Catch-Finally 문부터 작성하라 </div>
+
+예외가 발생할 수 있는 코드를 짜는 경우 try-catch-finally 문으로 시작하자. try-catch-finally 구문은 하나의 트랜잭션과도 같아서 try 블록에서 무슨 일이 일어나든지 catch 블록이 프로그램 상태를 일관성있게 유지해준다. 따라서 try 내부에서 어떤 일이 발생하더라도, expect result의 type이나 상태를 정의하기 쉬워진다.
+
+아래 예제를 살펴보자.
+
+**파일을 열어서 직렬화된 객체 몇 개를 읽어 들이는 코드가 필요하다는 요구사항**을 가정하자. 아래 코드는 파일이 없으면 예외를 던지는지 확인하는 단위 테스트 코드이다. 
+
+```java
+@Test(expected = StorageException.class)
+ public void retrieveSectionShouldThrowOnInvalidFileName() {
+     sectionStore.retrieveSection("invalid - file");
+}
+```
+
+테스트에 맞춰 아래 코드를 구현했다.
+
+```java
+public List<RecordedGrip> retrieveSection(String sectionName) {
+    // 실제로 구현할 때까지 비어 있는 더미를 반환한다.
+    return new ArrayList<RecordedGrip>();
+}
+```
+
+반면 해당 함수는 예외를 던지지 않기 때문에 단위 테스트가 실패로 나온다. 잘못된 파일 접근을 시도하도록 구현을 아래처럼 변경하자.
+
+```java
+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을 잡아내자.
+
+```java
+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 블록의 트랜잭션 범위부터 구현하게 되므로 트랜잭션의 본질을 유지하기 쉬워진다.
+<br><br>
+
+## <div id="미확인">미확인 예외를 사용하라 </div>
+
+자바 첫 버전에서 선보인 checked exception은 멋진 아이디어처럼 보였다. 메소드 선언시 메소드가 반환할 예외를 모두 열거했다. 또한 코드가 메소드를 사용하는 방식이 이 선언과 일치하지 않으면 컴파일도 안됐다.
+
+반면 이제는 안정적인 소프트웨어를 제작하는데 checked exception가 반드시 필요하지 않다는 사실이 분명해졌다. 그러므로 checked exception가 그것을 사용하는 비용 이상의 가치를 제공하는지 다시 한 번 생각해보자.
+
+가장 먼저 checked exception은 OCP(Open Closed Principle)을 위반한다. 하위단계에서 코드를 변경하면, 그것을 사용하는 모든 함수의 선언부에 올라가서 전부 exception을 추가해줘야 한다.
+
+또한, checked exception은 캡슐화를 깨뜨린다. throws 경로에 위치하는 모든 함수가 최하위 함수의 예외를 파악하고 있어야 하기 때문이다. (하나라도 빠뜨리면 컴파일 에러가 뜨게 된다!) 
+
+```java
+//checked exception을 사용하는 경우 아래 상위 코드인 func에서도 FileNotFoundException을 선언해야 한다.
+ public void func(String filename) throws FileNotFoundException {
+     FileInputStream fis = openFile(filename);
+     ...
+ }
+ public void openFile(String filename) throws FileNotFoundException {
+        try {
+            FileInputStream stream = new FileInputStream(sectionName);
+            stream.close();
+        } catch (FileNotFoundException e) {
+            throw new StorageException("retrieval error", e);
+        }
+ }
+```
+
+아주 중요한 라이브러리를 만드는 경우 모든 예외를 잡아서 checked exception으로 명시하는 것은 유용할 수 있다. 하지만 **일반적인 application에서는 이익보다는 checked exception으로 인한 의존성이라는 비용이 훨씬 더 커지게 된다.**
+<br><br>
+
+## <div id="의미">예외에 의미를 제공하라 </div>
+
+아주 중요한 부분인데, 예외를 던질 때는 오류 메세지에 전후 맥락과 상황을 충분히 쉽게 이해할 수 있도록 작성해주자. 자바는 모든 예외에 call stack을 제공하지만 이 정보만으로는 부족한 상황이 있다.
+
+오류 메세지를 정확히 명시해준다면, 오류가 발생한 원인과 위치를 찾기 용이해진다. 실패한 연산의 이름과 실패 유형 등을 기록해주고, application에서 logging을 사용한다면, catch 블록에서 더 자세한 정보를 로그로 남겨 오류에 대한 충분한 정보를 기록해주자.
+
+<br><br>
+
+## <div id="호출자">호출자를 고려해 예외 클래스를 정의하라 </div>
+
+프로그래머가 application에서 오류를 정의할 때(혹은 예외 코드를 작성할 때) 가장 중요한 신경써야하는 것은 **오류를 잡는 방법이 되어야 한다.**
+
+아래 코드를 보자.
+
+**Bad:**
+```java
+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 {
+     ...
+ }
+```
+
+위와 같이 에러를 잡고 있었다면 해당 레포지토리를 더 열심히 읽자. 위 코드에서 반복되는 중복 코드들은 그렇게 놀랍지도 않다. 그렇다면 이를 어떻게 개선해야 할까?
+
+사실 생각해보면, 대부분의 상황에서 우리가 에러를 처리하는 방식은 비교적 일정하다. 보통 아래와 같은 절차를 밟는다.
+
+> 1. 오류를 기록한다.
+> 2. 프로그램을 계속 진행해도 좋은지 확인한다.
+
+위 코드의 경우 특히 예외에 대응하는 방식이 완전히 동일하기 때문에 코드를 간결히 고치기 더 쉬워진다. 호출하는 라이브러리 API를 감싸면서 예외 유형 하나를 반환하면 된다.
+
+**Good:**
+```java
+        LocalPort port = new LocalPort(12);
+        try {
+            port.open();
+        } catch (PortDeviceFailure e) {
+            reportError(e);
+            logger.log(e.getMessage(), e);
+        } finally {
+         ...
+        }
+```
+```java
+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);
+        }
+    }
+     ...
+}
+```
+
+위의 LocalPort 클래스는 단순히 ACMEPort 클래스가 던지는 예외를 잡아 변환해주는 Wrapper 클래스이다. 이 방법은 실제로 외부 API를 사용할 때는 최적의 방법이다. 아래와 같은 장점들을 제공해주기 때문이다.
+
+> 1. 외부 라이브러리와 프로그램 사이의 의존성이 크게 줄어든다.
+> 2. 나중에 다른 라이브러리로의 교체가 용이하다. (코드를 크게 뜯어고칠 필요가 없어진다.)
+> 3. Wrapper 클래스에서 외부 API를 호출하는 대신, 테스트 코드를 넣어주는 방법으로 프로그램을 테스트하기도 쉬워진다.
+> 4. 특정 업체가 API를 설계한 방식에 발목 잡히지 않는다. 프로그램에 적합하고, 사용하기 편리한 API로 정의하면 된다. 
+
+당장 위 예제만 봐도 port 디바이스 실패를 표현하는 예외 유형을 하나만 정의해도 이렇게 프로그램이 깔끔해진 모습을 볼 수 있다.
+
+예외 클래스에 포함된 정보로 오류를 구분해도 괜찮은 경우는 예외 클래스가 하나만 있어도 충분하다. 반면, 한 예외는 잡아내고 어떤 예외는 무시해도 괜찮은 경우라면, 여러 예외 클래스를 사용하자.
+<br><br>
+
+## <div id="정상">정상 흐름을 정의하라 </div>
+
+
+<br><br>
+
+## <div id="null반환">null을 반환하지 마라 </div>
+
+
+
+<br><br>
+
+## <div id="null전달">null을 전달하지 마라 </div>
+
+
+
+<br><br>
+
+## <div id="결론">결론 </div>
+
+
+
+<br><br>
