데코레이터 패턴으로 디스코드 봇 에러 핸들링 구현

[hye-on]

🔗 관련 이슈

resolves #20

📝 작업 내용

• 기존 try-catch 방식 제거 후 데코레이터 패턴 (@CatchError) 적용
• AppException, BaseException을 활용한 예외 계층 구조 정리
• DiscordAPIError, RateLimitError 등 주요 에러 유형을 분류하고, 사용자에게 적절한 메시지 제공
• 글로벌 로거 모듈 적용

🍇 고민한 부분

1. Exception Filter가 동작하지 않는 문제

NestJS의 Exception Filter는 ExecutionContext를 기반으로 HTTP, WebSocket, RPC 등 요청-응답 생명주기를 전제로 합니다.
그러나 Discord.js는 이러한 파이프라인을 사용하지 않기 때문에 Exception Filter가 호출되지 않습니다.

문제 원인
NestJS의 ExceptionFilter는 ExecutionContext를 활용하는데, Discord.js의 이벤트는 이를 제공하지 않습니다.
host.switchToHttp()나 host.switchToWs()와 같은 컨텍스트 전환이 불가능합니다.
기본 ArgumentsHost의 지원 범위에 Discord.js 이벤트가 포함되지 않습니다.

해결책
메서드 데코레이터 기반 에러 핸들링 패턴을 적용하여, 각 함수 실행 전후에 에러를 자동 감지하고 처리하도록 하였습니다.

2. 에러 핸들링 패턴 선택

Exception Filter를 대신할 방법을 찾기 위해 여러 에러 핸들링 패턴을 검토했습니다.

데코레이터 패턴

• @ CatchError 데코레이터를 사용하여 선언적으로 에러 처리 가능
• 중복된 try-catch 제거하여 코드 가독성 및 유지보수성 향상
• Discord.js의 이벤트 모델과 자연스럽게 통합 가능

이벤트 기반 중앙처리 방식

• 모든 에러를 한 곳에서 처리 가능하지만, 컨텍스트 전달이 어려워지고 로직이 복잡해질 수 있음

미들웨어 체인 방식

• 처리 단계를 동적으로 구성할 수 있으나, 실행 순서 관리가 까다롭고 오버엔지니어링이라고 생각

EventEmitter 방식

• 느슨한 결합을 유지하면서 에러 처리가 가능하지만, 에러 추적이 어려움

최종 선택: 데코레이터 패턴

3. Either (Monad) 기반 Result 패턴을 고려하였지만 사용하지 않은 이유

Either<T, E> 패턴은 비즈니스 로직에서 명시적으로 성공과 실패를 다룰 수 있어 유지보수성과 테스트 용이성이 높아지는 장점이 있습니다. 특히 복잡한 결제 시스템이나 도메인 로직에서 비즈니스 에러를 명확하게 표현하는 데 유용합니다.
그러나 Discord.js의 API와 맞지 않고 현재 서비스에서는 복잡한 비지니스 로직이 적어 오버엔지니어링이라고 판단하였습니다.