4장 - 오류

런타임은 불안정해

• 사용자가 잘못된 값 입력
• 외부 시스템 다운
• 내가 작성한 코드에서 버그

 

이런 점들을 고려했을 때 오류는 불가피합니다.

따라서 오류 사례에 대해서 잘 구분하여 잘 처리해야 신뢰성 높은 코드를 작성할 수 있습니다.

 

복구 가능한 오류

사용자가 값을 잘못 입력했는데 전체 시스템이 작동을 멈춘다면 어떨까요?

이는 바로 좋지 않은 사용자 경험으로 이어지게 됩니다.

그보다는 사용자가 유효하지 않은 입력을 수행하면 오류 메시지를 제공하고 올바른 번호를 입력받도록 요청할 수 있습니다.

 

이외에도 통계를 기록하는 부분과 같이 비즈니스에 중요하지 않은 부분이나, 몇 초 뒤에 다시 시도해서 해결되는 네트워크 오류 등은 복구 가능한 오류입니다.

 

이런 오류들은 일어날 가능성이 높다고 판단해야 하며 오류가 발생해도 시스템이 잘 동작하도록 유의해야 합니다.

 

복구할 수 없는 오류

개발자가 프로그래밍을 잘못하여 항상 발생하는 케이스

 

오류는 최대한 빠르게 인지할 수 있도록 한다.

• Controller에서 Request가 잘못 들어온 것을 검증하는 경우
• Repository에서 Save전에 잘못들어온 것을 검증하는 경우

 

두 케이스에 대해서 비교해보면 Repository에서 오류가 발생하면 해당 stackTrace가 Service, Controller부터 시작됩니다.

신속하게 실패하면 실제 발생 지점으로부터 가까운 곳에서 오류가 나타나기 때문에 개발자도 신속하게 문제를 파악할 수 있습니다.

 

요란하게 실패하기

소프트웨어에서 버그가 발생하였을 때 인지를 빠르게 하기 위한 방법입니다.

우리는 버그를 수정하고 싶지만, 버그가 언제 일어났는지 인지하지 못하면 고칠 수 있는 방법이 없습니다.

가장 명백한 경우는 예외가 발생하면 프로그램이 중단되게 하는 것입니다.

이렇게 되면 개발 도중이나 테스트하는 동안에 버그가 발견될 가능성이 매우 큽니다.

 

 

오류를 숨기지 않기

예를 들어 계좌 조회를 했을때 잔액이 10,000원인 고객에게 오류가 발생해서 기본값 0을 내려준다면 이는 굉장한 혼란을 야기할 수 있습니다.

이 보다는 "죄송합니다. 지금 이 정보에 접근할 수 없습니다"라는 오류 메시지가 더 나은 선택지입니다.

 

이외에도 단순하게 return, try-catch 등을 활용하여 오류를 숨기지 않아야 할 때를 적절하게 선택해야 합니다.

 

Result 유형을 만들어서 예외 전달해 보기

null이나 optional 타입을 반환할 때의 문제 중 하나는 오류 정보를 전달할 수 없다는 것입니다.

따라서 언어차원에서 지원하지 않더라도 제네릭으로 만들어서 error의 원인도 같이 반환해 주면 좋습니다.

 

아웃컴 반환

성공 시 true, 실패 시 false 등을 반환하는 방법입니다.

하지만 return 값을 호출하는 쪽에서 무시해 버리면 의미가 없어집니다.

Java의 경우에는 CheckReturnValue 어노테이션으로 함수의 반환값을 무시하면 컴파일러가 경고를 생성하도록 함수를 표기할 수 있습니다.

 

해당 글을 보고 실제로 @CheckReturnValue 어노테이션을 사용해봤지만 컴파일러가 경고를 따로 생성해주진 않는것 같습니다.

 

오류 전달 기법

• 명시적 방법: 호출하는 쪽에서는 오류가 발생할 수 있음을 인지한다.
• 암시적 방법:호출하는 쪽에서 오류 발생 여부를 인지하지 못할 수 있음

 

책에서는 명시적인 기법 추천합니다.