---

책의 예시들을 typescript로 작성하였습니다. 의미가 안 맞을 수 있지만 최대한 비슷한 느낌으로 작성하려 노력했습니다🥺

---

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

• 예외를 던지는 것이 명확하고, 처리 흐름이 깔끔해진다.

예외를 던지고, 처리하는 방식

1. 오류가 발생한 부분에서 예외를 던진다. try/catch

예외에 의미를 제공하라

예외에 의미있는 정보 담기

• 오류가 발생한 원인과 위치를 찾기 쉽도록, 예외를 던질 떄는 전후 상황을 충분히 덧붙인다.
• 실패한 연산 이름과 유형 등 정보를 담아 예외를 던진다.

실무 예외 처리 패턴

getOrElse

• 예외 대신 기본 값을 리턴
  1. null이 아닌 기본 값
  2. 도메인에 맞는 기본 값

// Bad
const employees: EmployeeType[]  = getEmployees();
if (employees !== null) {
  ...
}

• getEmployees를 설계할 때, 데이터가 없는 경우를 null로 표현했는데, 다른 방법이 없을까? null을 리턴한다면 이후 코드에서 모두 null 체크가 있어야 한다.

// Good
function getEmployees() {
	...
	if (..there are no employee..) {
		return [];
	}
}

const employees: EmployeeType[]  = getEmployees();  
...

• 복수형의 데이터를 가져올 때는 데이터의 없음을 의미하는 컬렉션을 리턴하면 된다. null 보다는 size가 0인 컬렉션이 훨씬 안전하다.
• 도메인에 맞는 기본값을 가져온다
  • 이런 식의 코드를 계속 읽다보면 논리적인 흐름인 끊긴다.
  • 이런 방법을 해결하기 위해 예외 처리를 데이터를 제공하는 쪽에서 처리해 호출부 코드를 심플하게 만든다.

getOrElseThrow

• null 대신 예외를 던진다 (기본 값이 없다면)
• null 체크 지옥에서 벗어나자
  • 데이터를 제공하는 쪽에서 null 체크를 하여, 데이터가 없는 경우엔 예외를 던진다.
  • 호출부의 가독성이 올라간다.

파라미터의 null을 점검하라

null을 전달하지 마라

• null을 리턴하는 것도 나쁘지만 null을 메서드로 넘기는 것을 더 나쁘다.
• null을 메서드의 파라미터로 넣어야 하는 API를 사용하는 경우가 아니면 null을 메서드로 넘기지 마라.