0. 들어가기에 앞서…

본 내용은 우리 회사 시스템에 맞춘 경험이기 때문에 일반적인 시스템과 다를 수 있으며, 주니어 개발자로서 회사의 공통 시스템에 기여하기 위한 과정을 기록한 글 입니다. 또한, 예시 코드는 이해를 돕기 위한 코드임을 미리 말씀드립니다.

1. API 공통에러 처리에 의문을 갖게 된 계기

회사에서는 핸들링 가능한 에러와 불가능한 에러를 동일한 로직으로 처리하고 있었다.

(핸들링 가능 - 응답 객체에 에러 메세지 포함, 불가능 - 메세지 응답)

// 핸들링 가능한 에러
type IAPIResponse<T> = {
	data: T[],
	err_msg: string,
};

// 핸들링 불가능한 에러
type APiError = string;

// 에러 핸들링
const fetch = async <T>() => {
	try {
		const res: IAPIResponse<T> =	await api();
		if(res.err_msg) throw Error(res_msg);
	
		return res;	
	} catch (error) {
		throw Error(error instanceof Error ? error.message : String(error));
	}
};

평소 이 부분에 대해 불편함을 느끼고 있었고, 신규 프로젝트를 진행하면서 원하는데로 설계할 수 있는 권한을 부여받았고, 프로젝트를 진행하면서 기존 프로젝트들에도 반영 할 수 있도록 리팩토링 가능한 에러 핸들링을 설계하기로 했다.

을 통해 핸들링 가능한 에러는 경고를 띄우고, 불가능한 에러만 대체 UI를 사용하기 위해 분리하기로 했다.

P.S. 에러의 분류

• https://velog.io/@himprover/프론트엔드-에러-핸들링에-대한-고민#에러-핸들링-과정-설계하기
• https://blog.hwahae.co.kr/all/tech/7867

2. API 공통 에러 설계

설계전 생각해야 할 것

- 회사 API 시스템은 에러코드가 없다.

- 핸들링 가능한 에러는 응답 객체에 에러 메세지를 포함한다.

- 핸들링 불가능한 에러는 응답 메세지만 보내준다.

- 운영서버에 바로 적용된다.

에러 처리 설계