상권's

TIL 59 (북담 서버 리팩토링2) 본문

~2022 작성 글/TIL

TIL 59 (북담 서버 리팩토링2)

라마치 2022. 2. 13. 18:03

22.02.12 try/catch 적용부분

  logout: async (req, res) => { // test done
    try {
      const cookie = req.cookies.jwt;
      if (!cookie) return res.status(401).json({ message: '로그인 유저가 아닙니다.' });
      let decodedData = isAuthorized(cookie, res)
      const findUser = await UserModel.findOne({
        where: { id: decodedData.id, userId: decodedData.userId }
      });
      if (!findUser) return res.status(400).json({ message: '유저가 없어 로그아웃에 실패했습니다.' });
      res.clearCookie('jwt').status(200).json({ message: '로그아웃 되었습니다.' });
    } catch(error) {
      // console.log(error)
      if(error.name === 'TokenExpiredError') return res.status(401).json({ message: '토큰 만료로 로그인이 필요합니다.', error : error});
      else {
        return res.status(400).json({ message: '로그아웃에 실패했습니다.', error : error });
      }
    }
  },

22.02.13 catch 수정 부분

try/catch를 통한 예외처리에서 다음과 같은 고민을 했습니다.

상황에 따라 에러메세지를 따로 주는 게 낫지 않을까?

모든 상황에 대해서 동일한 에러 메세지가 간다면 클라이언트에서 에러 처리가 복잡해질 것이고, 유저의 UX가 나빠질 것 같았습니다.

 

그럼에도 현재의 북담은 axios 서버요청에 따른 alert나 에러 팝업이 별도로 처리되어있지 않아 일단은 에러 메세지를 크게 묶어 예외처리를 진행했습니다.

 

토큰 만료나 토큰이 없을 경우 => 로그인 유저가 아닙니다.

쿠키에 대한 정보로 db에서 유저를 찾을 때 발생하는 에러 => 로그아웃에 실패했습니다.

> db에 값이 없더라도 정상적으로 findOne 메소드가 작동하면 res로 넘어가기 때문에 !findUser를 추가적으로 넣어줬습니다.

사실 이 부분은 로그인이 되었다라는 전제조건이 따라오기 때문에 필요 여부에 대해서 고민이 됩니다. 해당 부분도 추가적으로 학습할 예정입니다.

 

프론트엔드 팀원들과 서버 요청 catch문을 처리할 수 있는 팝업이나 alert를 추가하는 방법에 대해 이야길 나눠봐야겠습니다.

 

'~2022 작성 글 > TIL' 카테고리의 다른 글

TIL 61 (북담 서버 리팩토링3)  (0) 2022.02.20
TIL 60 (복습)  (0) 2022.02.16
TIL 58 (북담 서버 리팩토링1)  (0) 2022.02.12
TIL 57 (복습)  (0) 2022.02.10
TIL 56 (복습)  (0) 2022.02.09
Comments