우리는 개발을 진행하다 보면 많은 에러에 부딪히게 됩니다.
이러한 에러는 어떤 종류가 있으며, 개발자가 어떤 자세를 취해야 하는지 알아봅시다!
우선, 나누는 방식에 따라 다르겠지만, 에러를 나누는 분류에는 크게 두 가지가 있습니다!!
이런 방식 등으로 우리는 에러라는 친구(?)를 다양하게 바라볼 수 있습니다.
앞서 나온 것처럼 앱 내부에서 문법 오류가 생기거나, 통신을 진행할 때 발생하는 모든 에러를 처리하는 과정을 에러 핸들링이라 합니다.
이러한 에러 핸들링은 왜 필요할까요? 사실 이 부분은 사용자 경험
과 밀접한 연관이 있습니다. 🤭
페이스북
같은 경우에는 서버 통신을 진행할 때, 에러코드와 메시지를 동시에 받아와 어디에서 에러가 발생했는지 추적한다고 합니다. 그 밖에도 runCatching
등의 코루틴을 통해서 저희는 에러 핸들링을 합니다.
try-catch
도 빠뜨릴 수가 없죠? 하지만 이러한 방식에는 큰 문제가 있습니다. 무분별한 사용은 오히려 코드의 가독성을 저하시켜 유지보수가 어렵게 된다는 문제가 있습니다.
그러면 저희는 언제 에러 핸들링을 해야 할까요? 바로, 논리 오류
가 발생한 시점이라 볼 수 있습니다.
논리 오류란, 프로그램이 강제로 종료되지도 않고 의도대로 동작하지도 않는 상황 을 논리 오류라고 부릅니다. 예외가 던져지지 않으므로 런타임에 발생하는 RuntimeException 과는 다른 상황입니다.
간단하게 예시를 들어볼까요? 저희는 라면이라는 객체를 만들려고 하는데 후레이크만 두 번 들어가버리면 스프는 들어가지 않게 됩니다. 이렇게 정해진 리턴값은 절대로 그대로 나오면 안되겠죠?? 이럴때 저희는 예외를 던져줘야 합니다.
이러한 상황에서 check()
나 require()
등을 통해 에러를 다룹니다. 간단하게 차이점을 설명하자면, 조건이 맞지 않는 상황에서 check()
는 IllegalStateExceptio
, require()
는 IllegalArgumentException
을 던져준다는 차이점이 있습니다.
사용하는 방법에 대해서는 구글에 많이 나와있으니 찾아봐도 좋을 것 같습니다. 이 밖에도 흔히 사용하는 run-catch
를 사용할 수도 있습니다.
아니면 토스
처럼 에러를 클래스에 위임하는 방식
등을 통해 우리는 이러한 오류를 미리 방지할 수 있습니다. 이 과정에서 Log
를 남기는 방법 등으로 개발자는 오류를 추적할 수 있습니다.
항상 예외 등을 던져 앱을 종료한다면 사용자는 답답하고 화가 날 것입니다. 자연스럽게 삭제 버튼으로 손이 가는 것은 자명하다고 생각합니다.
그렇다면 저희는 사용자가 어떤 화면을 보게 해야 할까요? 헤이딜러
같은 경우에는 다음과 같은 에러창을 띄워준다고 합니다.
이러한 오류창을 통해 사용자는 오류가 발생했음을 알 수 있고, 어떻게 행동해야 하는지 가이드까지 제시해주는 좋은 사례라고 볼 수 있습니다. 앞서 나온 에러 핸들링을 해야 하는 이유를 모두 반영해주는 모습을 볼 수 있습니다.
앱을 터뜨려야 할지, 아니면 빈 화면을 보여줄지, 위와 같은 에러 화면을 보여줄지 등은 어디까지나 정답이 있는 부분은 아니니 참고해주시면 좋을 것 같습니다. 유튜브
같은 경우에는 댓글이 0
개로 나와도 눌러보면 댓글이 보이는 것처럼 말이죠.
제가 아는 서비스 중 포포리
나 카카오페이
에서는 배포된 앱에서 오류가 발생했을 경우 Sentry
를 통해 개발자에게 알림이 오도록 만듭니다.
이를 에러 리포팅 서비스
라고 하는데, Google Analytics
, URQA
, Userhabit
, Fabric
등이 이에 속합니다. 사용하는 방법에 관해서는 구글에 검색해보면 많은 레퍼런스를 확인하실 수 있습니다.
이러한 리포팅 서비스를 통해 우리는 QA 과정에서 발생하지 않은 오류를 확인할 수 있고 대처할 수 있는 능력을 얻게 되었습니다!!
사실 앞서 말씀드린 것처럼 이 부분 역시 정답은 없습니다. 🤔 팀원과 함께 머리를 맞대고 어떤 방법이 효율적일지, 취향대로 선택하시면 좋을 것 같아요!!