에러를 대처하는 자세

GongBaek·2024년 5월 23일
0
post-thumbnail

📍 에러(Error)란 뭘까요?


에러가 뭘까요?

우리는 개발을 진행하다 보면 많은 에러에 부딪히게 됩니다.
이러한 에러는 어떤 종류가 있으며, 개발자가 어떤 자세를 취해야 하는지 알아봅시다!

에러의 종류

우선, 나누는 방식에 따라 다르겠지만, 에러를 나누는 분류에는 크게 두 가지가 있습니다!!

  • 예측 가능한 에러: 코드의 로직을 잘못 짰다거나, 오타 등으로 인해 발생하는 에러입니다. 예를 들어 REST API 통신을 진행할 때 Body값에 오타가 있다면 통신 에러가 발생하겠죠?
  • 예측 불가능한 에러: 프론트엔드의 입장에서 말해보자면, 갑자기 사용인원이 몰려 서버가 터지는 것도 에러라고 볼 수 있습니다. 하지만 이러한 부분은 저희가 대처가 불가능하겠죠?

이런 방식 등으로 우리는 에러라는 친구(?)를 다양하게 바라볼 수 있습니다.

에러 핸들링이란?

앞서 나온 것처럼 앱 내부에서 문법 오류가 생기거나, 통신을 진행할 때 발생하는 모든 에러를 처리하는 과정을 에러 핸들링이라 합니다.

이러한 에러 핸들링은 왜 필요할까요? 사실 이 부분은 사용자 경험 과 밀접한 연관이 있습니다. 🤭

  • 사용자가 에러인지 인지: 예측된 정보가 화면에 나타나지 않는다면, 사용자는 굉장히 당황할 거예요! 이 과정에서 사용자에게 오류 메시지를 띄워주거나 하는 인터랙션을 통해 사용자에게 오류임을 인지시켜줘야 합니다.
  • 어떤 행동을 해야하는지 인지: 오류임을 알아도 사용자는 어떻게 행동해야 하는지 모르겠죠? 이를 유도해줘야 합니다. 극단적인 경우에는 앱을 터뜨려서 종료시킬 수도 있어요!
  • 유지보수성 향상: 이친구는 항상 어디에도 빠뜨릴 수 없는 친구죠? 우리는 어디서 에러가 나는지 확인하고, 이를 수정하기 위해 에러를 추적할 수 있어야 해요! 이 역시 에러 핸들링을 통해 이루어집니다 😁

어떻게 에러 핸들링을 해야할까?

페이스북 같은 경우에는 서버 통신을 진행할 때, 에러코드와 메시지를 동시에 받아와 어디에서 에러가 발생했는지 추적한다고 합니다. 그 밖에도 runCatching 등의 코루틴을 통해서 저희는 에러 핸들링을 합니다.

try-catch 도 빠뜨릴 수가 없죠? 하지만 이러한 방식에는 큰 문제가 있습니다. 무분별한 사용은 오히려 코드의 가독성을 저하시켜 유지보수가 어렵게 된다는 문제가 있습니다.

언제 에러 핸들링을 해야할까?

그러면 저희는 언제 에러 핸들링을 해야 할까요? 바로, 논리 오류 가 발생한 시점이라 볼 수 있습니다.

논리 오류란, 프로그램이 강제로 종료되지도 않고 의도대로 동작하지도 않는 상황 을 논리 오류라고 부릅니다. 예외가 던져지지 않으므로 런타임에 발생하는 RuntimeException 과는 다른 상황입니다.

간단하게 예시를 들어볼까요? 저희는 라면이라는 객체를 만들려고 하는데 후레이크만 두 번 들어가버리면 스프는 들어가지 않게 됩니다. 이렇게 정해진 리턴값은 절대로 그대로 나오면 안되겠죠?? 이럴때 저희는 예외를 던져줘야 합니다.

이러한 상황에서 check()require() 등을 통해 에러를 다룹니다. 간단하게 차이점을 설명하자면, 조건이 맞지 않는 상황에서 check()IllegalStateExceptio, require()IllegalArgumentException 을 던져준다는 차이점이 있습니다.

사용하는 방법에 대해서는 구글에 많이 나와있으니 찾아봐도 좋을 것 같습니다. 이 밖에도 흔히 사용하는 run-catch 를 사용할 수도 있습니다.

아니면 토스 처럼 에러를 클래스에 위임하는 방식 등을 통해 우리는 이러한 오류를 미리 방지할 수 있습니다. 이 과정에서 Log 를 남기는 방법 등으로 개발자는 오류를 추적할 수 있습니다.

사용자는 어떤 화면을 봐야 할까?

항상 예외 등을 던져 앱을 종료한다면 사용자는 답답하고 화가 날 것입니다. 자연스럽게 삭제 버튼으로 손이 가는 것은 자명하다고 생각합니다.

그렇다면 저희는 사용자가 어떤 화면을 보게 해야 할까요? 헤이딜러 같은 경우에는 다음과 같은 에러창을 띄워준다고 합니다.

이러한 오류창을 통해 사용자는 오류가 발생했음을 알 수 있고, 어떻게 행동해야 하는지 가이드까지 제시해주는 좋은 사례라고 볼 수 있습니다. 앞서 나온 에러 핸들링을 해야 하는 이유를 모두 반영해주는 모습을 볼 수 있습니다.

앱을 터뜨려야 할지, 아니면 빈 화면을 보여줄지, 위와 같은 에러 화면을 보여줄지 등은 어디까지나 정답이 있는 부분은 아니니 참고해주시면 좋을 것 같습니다. 유튜브 같은 경우에는 댓글이 0 개로 나와도 눌러보면 댓글이 보이는 것처럼 말이죠.

릴리즈된 앱에서는 이를 어떻게 추적하면 좋을까?

제가 아는 서비스 중 포포리카카오페이 에서는 배포된 앱에서 오류가 발생했을 경우 Sentry 를 통해 개발자에게 알림이 오도록 만듭니다.

이를 에러 리포팅 서비스 라고 하는데, Google Analytics, URQA, Userhabit, Fabric 등이 이에 속합니다. 사용하는 방법에 관해서는 구글에 검색해보면 많은 레퍼런스를 확인하실 수 있습니다.

이러한 리포팅 서비스를 통해 우리는 QA 과정에서 발생하지 않은 오류를 확인할 수 있고 대처할 수 있는 능력을 얻게 되었습니다!!

글을 마치며

사실 앞서 말씀드린 것처럼 이 부분 역시 정답은 없습니다. 🤔 팀원과 함께 머리를 맞대고 어떤 방법이 효율적일지, 취향대로 선택하시면 좋을 것 같아요!!

profile
Junior Android Developer

0개의 댓글