1. 회원가입 오류처리

1-1. 의존성 주입 routes/signup.ts

회원가입시 워크스페이스 생성을 연결하기 위해서 의존성 주입하는데, workspaceRepository를 어떻게 연결해야할지 모르겠어서 생긴 오류

<바꾸기 전 코드>

< ✅ 해결한 코드>
WorkspacesRepository의 생성자에서 BoardsRepository의 인스턴스가 필요해서 생긴 오류. routes에서 import해주고, 안에 constructor 확인해서 인자에 담아주기

1-2. 배포환경 HTTPS에서 잘 작동하는지 확인하는 법 ❓

https: 웹에서 데이터를 암호화하여 보안을 강화하는 프로토콜 (자물쇠 → 안전한사이트)

• 변경된 사항을 github에 push하면 약 1분 이후에는 deploy되면서 바뀐 코드로 확인가능 (CI/CD 프로세스)

✅문제점 :

배포사이트로 들어가서 회원가입을 확인하는 과정에서 가입된 이메일로 중복가입을 해도 오류라는 코드가 뜨지 않음 (prisma studio로 확인시, 데이터가 중복으로 저장되지는 않음, 그러나 개발자도구에서도 오류코드를 확인할 수 없음 → 왜 오류처리가 안되는거지❓)

• 과정 image

✅해결방법 : throw / return 차이

src/services/signup.ts 에서 코드를 확인해보니, error처리가 아니라, return 으로 작성되어있음.

throw new CustomError( 409, ‘중복된 이메일입니다.’)

이렇게 작성해야 CustomError를 발생시킴 - 오류가 발생되면 함수 실행이 중지되고 try~catch 블록으로 제어가 전달됨

참고로 return 은 단순히 {} 객체 값을 반환하고, throw가 오류를 명확하게 알리는 방법

추가사항 ) 다른 에러코드 위치를 services →controllers 로 변경함

<에러처리 어느 곳에 위치해야할까❓>

• controller: 입력데이터에 대한 검증, req, res에 대한 에러처리 대게 컨트롤러
• service: 비즈니스 로직에 관한 규칙과 에러처리
• repository: 데이터베이스 관련 에러처리

+각 계층의 책임에 따라 에러처리의 위치가 결정된다!

1. Repository:

• 데이터베이스와 직접 상호 작용하는 계층입니다.
• 여기에서는 데이터베이스 특정 오류(예: 연결 실패, 쿼리 오류 등)를 처리합니다.
• 보통 데이터베이스 오류를 잡아내고, 이를 추상화된 오류로 변환하여 상위 계층으로 전달하는 역할을 합니다.

2. Service:

• 비즈니스 로직을 수행하는 계층입니다.
• 여기에서는 비즈니스 규칙 위반, 유효성 검사 오류 등 비즈니스 관련된 오류를 처리합니다.
• 서비스 계층에서 발생하는 오류는 주로 컨트롤러에서 처리되거나, 명시적으로 상위 계층으로 전달됩니다.

3. Controller:

• HTTP 요청을 수신하고 응답을 반환하는 계층입니다.
• 여기에서는 사용자 입력에 대한 유효성 검사 오류나 서비스 계층에서 발생한 오류를 처리합니다.
• 주로 HTTP 상태 코드와 함께 오류 메시지를 클라이언트에 반환하는 역할을 합니다.

4. Routes (or Router):

• HTTP 경로와 해당 경로에서 수행될 함수나 컨트롤러를 연결하는 계층입니다.
• 일반적으로 여기에서는 특정 에러 처리를 하지 않습니다. 대신에 미들웨어를 사용하여 일반적인 에러 처리(예: 404 Not Found)를 할 수 있습니다.

👉 최종적으로, 에러 처리의 위치는 프로젝트의 구조와 개발 팀의 선호에 따라 다를 수 있습니다. 그러나 일반적인 원칙은 각 계층에서 해당 계층의 책임 범위 내에서 발생하는 오류만을 처리하는 것입니다.