[실습] try...catch 없이 API 오류를 안전하게 처리하는 방법 (feat : Toast 및 Alert 컴포넌트 작성)

[@cheshirebizz]

요점은 클라이언트에 제공되는 api 자체를 미리 error handler로 감싸두는 것이라고 보면 될까요?

[@bgprogramming7929]

주어진 문제만 생각하면 그렇습니다.
하지만 제가 강조하고 싶었던 부분은 에러 핸들링을 미리 감싸두는 것 자체가 아니라, 문제를 해결하는 사고 방식과 패턴에 관한 것입니다.
특히 라이브러리나 프레임워크를 설계할 때 고려해야 할 두 가지 중요한 측면을 말씀드리고자 합니다.
1. 사용자 인터페이스 우선 설계
함수의 사용자 인터페이스를 먼저 설계하는 것은 중요한 접근 방식입니다.
개발자가 try...catch를 사용해야 한다는 것은 결국 해당 API를 사용하는 사람에게 반복적인 작업을 요구한다는 뜻입니다.
따라서, 먼저 어떻게 API를 더 쉽게 사용할 수 있을지를 생각해보고, 그런 후에 내부 구현을 통해 사용자에게 편의성을 제공하는 것이 좋습니다.
예를 들어, withCallback() 함수는 개발자가 자주 사용하는 람다함수 작성 방식으로 함수 사용을 직관적으로 사용할수 있게 처리했으며, 일일이 에러 처리를 생각하지 않아도 되도록 설계되었습니다.
2. 실수를 없애는 라이브러리및 프레임워크 설계
프레임워크나 라이브러리를 설계할 때, 개발자가 쉽게 실수할 수 있는 부분을 내부적으로 처리하여 안정성을 높여주는 것이 중요합니다.
즉, 개발자에게 에러 처리의 책임을 떠넘기지 않고, 함수나 프레임워크 자체에서 에러를 감싸고 필요한 처리를 하도록 설계함으로써, 사용자가 실수할 여지를 최소화하는 것입니다.
이러한 설계 철학은 다른 영역에서도 자주 등장합니다.
예를 들어, 백엔드 개발에서 데이터베이스 쿼리를 다룰 때, DB connect를 제대로 릴리즈하지 않으면 connection이 유지되어 나중에는 더 이상 연결할 수 있는 리소스가 남아 있지 않을 수 있습니다.
이게 만일 발견하기 쉬운 상황에서 실수하면 바로 고칠수 있지만, 운이 나빠 조건이 몇번 중첩되는 희귀한 상황에서 개발자가 DB연결을 release하는 코드를 빠트릴 수 있습니다.
이 경우에는 사고가 지금 터지는 것이 아니라 상황이 누적되어 몇달후에 서버에 문제가 발생할 수 있습니다.
규모가 있는 프로젝트에서 이런 버그는 상당히 찾기 어려울 수 있습니다.
이에 개발자가 실수할 여지를 애초에 없애버리는 것은 프레임워크와 라이브러리를 만들때 중요한 고려사항일 수 있습니다.
withCallback()의 예시도 이러한 철학에 기반하여, 비동기 작업에서 발생할 수 있는 오류를 안전하게 처리하고 있습니다.