7.3 API 에러 핸들링
비동기 API 호출 하다 보면 상태 코드에 따라
401 : 인증되지 않은 사용자
404 : 존재하지 않는 리소스
500 : 서버 내부 에러
CORS 에러
등 다양한 에러가 발생 가능
TS에서는 어떻게 이러한 에러를 어떻게 처리하고 명시할까
.
.
.
1. 타입 가드 활용하기
Axios 라이브러리 : Axios 에러에 대해 isAxiosError라는 타입 가드 제공.
: 서버 에러임을 명확하게 표시, 서버에서 내려주는 에러 응답 객체에 대해서도 구체적으로 정의 -> 에러 객체가 어떤 속성을 가졌는지 파악 가능
2. 에러 서브클래싱하기
실제 요청을 처리할 때 단순한 서버 에러 + 인증 정보 에러 + 네트워크 에러 + 타임 아웃 에러 등등 다양한 에러 발생.
-> 더욱 명시적으로 표시하기 위해 서브클래싱 활용 가능.
서브클래싱 Subclassing
: 기존 클래스(상위 또는 부모) 확장 -> 새로운 클래스(하위 또는 자식) 만드는 과정
새로운 클래스는 상위 클래스의 모든 속성과 메서드를 상속받아 사용 가능, 추가적인 속성과 메서드 정의 가능.
서블클래싱 활용 ( -> 명시적으로 에러처리 가능 )
: 에러가 발생햇을 때 코드상에서 어떤 에러인지를 바로 확인 가능
: 에러 인스턴스가 무엇인지에 따라 에러 처리 방식 다르게 구현 가능.
3. 인터셉터를 활용한 에러 처리
Axios 같은 패칭 라이브러리는 인터셉터 기능을 제공, 이를 사용하면 HTTP 에러에 일괄된 로지기 적용 가능.
4. 에러 바운더리를 활용한 에러 처리
에러 바운더리 : 리액트 컴포넌트 트리에서 에러가 발생할 때 공통으로 에러릍 처리하는 리액트 컴포넌트.
-> 리액트 컴포너느 트리 하위에 있는 컴포넌트에서 발생한 에러 캐치, 해당 에러를 가장 가까운 부모 에러 바운더리레어 처리하게 할 수 있음.
-> 에러 바운더리는 에러가 발생한 컴포넌트 대신에 에러 처리를 하거나 예상치 못한 에러를 공통 처리할 때 사용 가능.
이외, 에러 바운더리에 로그를 보내는 코드를 추가하여 예상치 못한 에러의 발생 여부 추적 가능.
5. 상태 관리 라이브러리에서의 에러 처리
에러 상태를 관리하지 않고 처리 가능하면 바로 처리(ex. 401 403)
바로 처리 가능x일 경우 -> reject로 넘겨줌.
이후, 액션 정의 -> setApCallError 사용 , 에럴르 상태로 처리.
이렇게 저장된 에러 -> 컴포넌트에서 사용 가능.
만약 MobX를 사용하고 있다면, 주로 스토어에서 에러 핸들링.
외부 : 별도로 성공, 실패 등에 대해 참조하지 않으며 비동기 동작의 수행 및 결괏값을 사용.
6. react-query를 홀용한 에러 처리
react-query나 swr과 같은 데이터 패칭 라이브러리 사용 -> 요청에 대한 상탤르 반환해줘서 요청 상태 확인 쉬움.
7. 그 밖의 에러 처리
- API 응답은 주로 성공시 2xx코드, 실패시 4xx, 5xx 코드 반환
일반적으로 API 요청 라이브러리에서도 HTTP 상태 코드에 따라 성공 응답인지 실패 응답인지 판단.
but!
: 비즈니스 로직에서의 유효성 검증에 의해 추가된 커스텀 에러는 200 응답과 함께 응답 바디에 별도의 상태 코드를 전달하기도 함.
도서참조 : 우아한 타입스크립트 with 리액트
