에러 헨들링에 관하여

버그는 개발자의 실수로 인해 발생하는 것이고, 에러는 사용자의 잘못된 사용 방식에 의해 발생하는 것입니다. 따라서, 버그가 없도록 개발하고 에러에 대한 예외 처리를 미리 준비하는 것이 좋은 방식입니다.

이제부터 에러에 대한 예외 처리를 '에러 핸들링'이라고 언급하겠습니다.

웹 애플리케이션에서 에러 핸들링은 크게 두 가지 방법이 있습니다. 하나는 클라이언트 사이드에서의 처리, 다른 하나는 서버 사이드에서의 처리입니다. 좀 더 간단히 말하면, 프론트엔드에서의 처리와 백엔드에서의 처리입니다. 각각에 대해 제 생각과 결론을 소개해보겠습니다.

클라이언트 사이드 (프론트엔드)

클라이언트 사이드에서는 사용자의 잘못된 행동을 막는 것이 중요합니다. 예를 들어, 접근할 수 없는 페이지로의 접근 시도를 막는 것이 있습니다. 이는 근본적으로 불가능한 행동을 사전에 차단하는 것입니다. 또한, 불필요한 네트워크 요청을 줄이는 것도 포함됩니다. 예를 들어, 입력 폼의 검증을 완료한 후에만 요청을 보내는 것이 이에 해당합니다.

포인트는 클라이언트 사이드에서는 데이터 자체에 대한 에러 핸들링이 불필요하다는 것입니다. 백엔드에서 처리한 후 적절한 에러 메시지를 보내주면, 이를 사용자에게 알맞게 노출시키면 됩니다.

서버 사이드 (백엔드)

서버 사이드에서는 잘못된 데이터, 설계와 어긋난 데이터에 대한 처리가 필요합니다. 예를 들어, 특정 데이터를 생성할 때 잘못된 정보나 누락된 정보에 대해 처리하는 것입니다.

실제 예시

백엔드를 자바 스프링(Spring)으로 구성하고, 프론트를 리액트(React)로 구성하였을 때, 서버에서 보낸 에러를 화면에 노출시키는 예시 코드를 작성해보겠습니다.

자바 스프링에서 에러가 발생했을 때 ResponseStatusException을 발생시킵니다. ResponseStatusException는 에러 코드와 메시지를 담아 에러를 응답할 수 있는 클래스입니다.

throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "message.");

이제 리액트(자바스크립트)에서 이 에러를 받아 사용자에게 노출시켜보겠습니다.

const request = async () => {
    const option = {
        method: "PUT",
    };

    try {
        const response = await fetch(`url`, option);
        if (response.ok) {
            toast.success("성공했습니다.");
        } else {
            const errorData = await response.json();
            throw new Error(errorData.message);
        }
    } catch (error) {
        toast.warn(error?.message);
    }
};

응답의 상태가 200(성공)이 아니라면 새로운 에러를 발생시키고, 그 에러를 catch 문에서 잡아서 화면에 노출합니다. (또는 에러 페이지로 이동하게 할 수도 있습니다.)

당분간 저는 이런 방식으로 작성할 것 같습니다. 물론 가장 중요한 것은 자신의 상황에 맞게 처리하는 것입니다. 협업하는 백엔드 개발자가 이 방식을 원치 않을 수도 있기 때문에, 커뮤니케이션을 통해 자신만의 적절한 처리 방법을 찾는 것이 중요합니다. 제 방식이 그 방법을 찾는 데 도움이 되었으면 좋겠습니다.

의견이나 지적은 언제나 환영합니다.