좋은 예외 처리 - dnwls16071/Backend_Summary GitHub Wiki

좋은 예외 처리가 무엇인지?

• 좋은 예외 처리는 견고한 프로그램을 만들고 좋은 사용자 경험을 준다.
• 예외 처리를 통해 애플리케이션이 예기치 않게 종료되는 것을 방지하고 갑작스런 종료 대신 사용자의 무엇이 잘못되었는가 그리고 가능하다면 어떻게 바로잡을 수 있을지에 대한 의미 있는 오류 메시지를 받을 수 있다.
• 회사에서도 개발을 하면서 예외 처리에 대한 좋은 메시지를 남기지 않아 쿠버네티스의 파드를 조회하며 그 문제를 찾곤 했었는데 좋은 백엔드 개발자로 성장하기 위해 예외 처리에 대한 포스팅을 읽고 정리한 내용을 남기려고 한다.

복구 가능한 오류와 불가능한 오류를 구분하자.

• 가장 먼저 생각할 것은 이 오류가 복구 가능한 오류인지 아니면 복구 불가능한 오류인지를 구분하는 것이다.
• 모든 예외에 대해서 동일한 방식을 적용할 수는 없다.
• 어떤 예외는 상시로 발생해서 무시할 수 있으며, 어떤 예외는 무시하면 절대 안되는 경우도 있다.
• 이들을 구분없이 다룬다면 사용자는 불편하고, 개발자는 상시로 발생하는 알람으로 점점 더 시스템의 문제에 등한시 하게 된다.
• 그래서 이들을 구분해서 예외가 발생했을때 어떻게 처리할지 결정해야 한다.

복구 가능한 오류

• 시스템 외적인 요소로 발생하는 치명적이지 않은 오류이다.
  • 사용자의 오입력
  • 일시적인 네트워크 오류
  • 서비스적으로 중요하지 않은 작업의 오류
• 복구 가능한 오류는 상시로 발생할 수 있다고 가정하고, 사용자(호출자)에게 가능한 문제 원인을 인지할 수 있게 해야한다.

복구 불가능한 오류

• 복구 불가능한 오류는 별도의 조치 없이 시스템이 자동으로 복구할 수 있는 방법이 없는 경우이다.
• 메모리 부족(Out of Memory) - 시스템이 필요한 메모리를 할당받지 못할 때 발생한다.
• 스택오버플로우(StackOverflow) - 재귀 함수가 너무 깊게 호출되어 스택 메모리가 고갈될 때 발생한다.
• 시스템 레벨의 오류 - 하드웨어 문제나 운영 체제의 중대한 버그로 인해 발생한다.
• 복구 불가능한 오류는 자주 발생하는 오류가 아니기 때문에 빠르게 개발자에게 문제 원인을 알려야한다.

null, -1, 빈 문자열 등 특수값을 예외로 사용하지 않기

• 예외 상황은 예외(Exception)로 처리해야 한다.
• Magic Number나 Magic String의 경우 정확한 컨텍스트를 아는 사람은 그 맥락을 이해하는데 많은 시간을 들이지 않지만 주변의 동료 개발자나 내 코드를 읽고 유지보수할 머나먼 후임 개발자에게 부메랑으로 돌아와 괴롭힐 것이다.

의미를 담고 있는 예외

• 코드의 가독성 향상: 의미 있는 이름을 가진 예외는 코드를 읽는 사람에게 문맥을 제공한다.
• 디버깅 용이성: 오류의 원인을 빠르게 파악하고 수정할 수 있다.