나는 항상 레트로핏을 사용한 API 통신 과정에서 다양한 에러(대표적으로 네트워크 에러)에 대해 어떻게 처리해야 할지 감이 잘 잡히지 않았다.
지금까지는 단순히 앱이 터지지 않게 runCating으로 막아두는 방식으로 에러를 다루는 것을 피해 왔지만 이번에 프로젝트를 잠시 쉬는동안 제대로 학습해 보고 프로젝트를 개선해 보기 위해 학습을 시작하게 되었다.
어떤 에러가 발생하는가
레트로핏을 사용하면서 처리해 주어야할 에러의 종류는 다양하다. api의 요청 자체가 잘못되었을 수도 있고 요청은 정상적으로 진행되었지만 서버의 문제로 응답을 받지 못할 수도 있다. 사용자의 단말기가 네트워크가 끊어져있어 통신을 하지 못할 수도 있고 가져온 데이터를 다루는 로직 상에서 일부로 Exception을 던질 수도 있을 것이다. 이러한 케이스들을 각각 구분하여 다른 상태를 사용자에게 전달해 주도록 하고싶었다.
어떻게 에러를 처리할 것인가
뷰모델에서 runCatching 사용
지금 까지 나는 모든 에러를 runCatching을 사용해 처리했다. 뷰모델에서 api를 요청할 때 runCatching을 사용하는 것으로 에러가 발생해도 앱이 죽지않고 성공 실패 결과에 따른 화면을 사용자에게 제공할 수 있었다. 그러나 다양한 에러를 처리하기에는 조금 문제가 있었고 매번 요청마다 runcatching을 수행해 줘야하는 번거로움과 그로인해 발생하는 많은 보일러플레이트 코드가 나를 찝찝하게 만들었다.
callAdapter를 통해 레트로핏의 Call을 커스텀
코틀린에서 suspend를 붙여 api서비스를 요청하면 내부적으로는 Call객체의 enqueue를 통해 비동기방식으로 요청을 수행하게 된다. 이 과정에서 callAdapter를 커스텀 하여 반환되는 값을 요청 결과에 따라 내가 원하는 형태로 가공하여 반환하게 하여 사용할 수 있을 것이다.
sealed class를 사용
통신의 결과를 담는 Wrapper Class를 sealed Class로 두어 api의 요청 과정에서 결과에 따른 Wrapper Class로 매핑한다면 뷰모델에서 결과에 따른 값을 바탕으로 uiState를 갱신할 수 있을 것이다.
