장고 과제 5(2) 문제 의도 및 추가적인 질문

[graviol]

요약

• 모든 500 에러에 대해 html 파일 등을 표시하여 서버에 알려달라는 문구를 띄우라는 것인지, 아니면 API 실행 중 특정한 500 에러에 대해 html 실행 대신 Django Rest Framework에서 메시지를 띄우라는 것인지가 헷갈립니다.
• exception_handler가 실제로는 모든 에러를 잡는 용도라기보다는 exception이 raise된 상황에서 잡히는 용도가 맞는 것인지, 아니면 모든 에러를 다 잡을 수 있어야 하는 용도인지 궁금합니다. 후자가 맞다면, 임의의 에러를 잡기 위해서 추가적으로 거쳐야 하는 절차가 있는지 알고 싶습니다.

상황 및 문제 내용

• 4시간 이상 2번 문제와 관련하여 구글링을 해보았으나 500 에러에 대한 처리에 대해서는 전부 html을 이용한 방법만 소개하고 있었습니다. 저도 그래서 임시로 다음과 같이 임의의 500 에러에 대해 아래와 같은 화면이 출력되도록 구현해놓긴 하였으나, 이것이 문제의 의도가 맞는지에 대해 의문이 듭니다. 또한 이 경우에는 다른 에러들이 어떠한 request를 통해 어떠한 이유에서 에러가 떴는지까지(예컨대 세미나 생성의 예시를 들 때 정원을 정수형으로 입력하지 않아 생기는 오류로 인해 400이 떴다면, 그 원인 문구를 수집할 수 있었습니다.) 모두 수집이 가능했던 것과는 대조적으로 500 에러를 따로 내부적으로는 감지할 수 없었습니다. (즉 request가 무엇이었는지 수집할 방법이 없었습니다.) 다만 제 생각에는 500 에러는 어차피 유저가 서버 관리자에게 직접 이러이러한 오류가 있다는 것을 알리면 충분하다고 생각하여, 이렇게 구현해도 딱히 문제가 없을 것 같다고 개인적으로는 생각했었습니다.
• 한편, 처음에 이 문제를 풀었다고 생각했을 때에는 적당한 API를 하나 만들어서 500 에러를 직접 raise하게 하는 경우에 대해 DRF에서 직접 메시지를 띄우는 것으로 이해하였는데, 그렇게 구현했을 때에는 다음과 같았습니다. 이 경우 해당 상황에 대해서는 에러 정보를 수집할 수 있었으나 임의의 500 에러에 대한 정보 수집 및 에러 메시지 처리는 가능하지 않았습니다.
• 두 경우 모두 올바른 의도가 아니라면, 문제의 정확한 의도가 무엇인지 말씀해주시면 감사하겠습니다. 그리고 참고할 만한 자료가 있다면 알려주시면 정말 감사드리겠습니다.
  
  
• 또한, 문제를 해결하는 과정에서 그간의 과제를 수행할 때에 구현했던 오류들에 대해 return response 형태는 exception_handler에서 감지하지 못 했던 한편, raise의 형태는 정상적으로 감지하는 것을 확인하였습니다. return response 등을 통해 나오는 오류 또한 감지가 이루어져야 하는지에 대해 궁금합니다. 만약 그렇다면, 임의의 에러를 잡기 위해 추가적으로 무엇을 설정해야 하는 작업 등이 있을까요?
  
  
  읽어 주셔서 감사합니다.

[Jhvictor4]

@graviol 형윤님, 답변이 늦어 죄송합니다.

4시간 이상 2번 문제와 관련하여 구글링을 해보았으나 500 에러에 대한 처리에 대해서는 전부 html을 이용한 방법만 소개하고 있었습니다. 저도 그래서 임시로 다음과 같이 임의의 500 에러에 대해 아래와 같은 화면이 출력되도록 구현해놓긴 하였으나, 이것이 문제의 의도가 맞는지에 대해 의문이 듭니다. 또한 이 경우에는 다른 에러들이 어떠한 request를 통해 어떠한 이유에서 에러가 떴는지까지(예컨대 세미나 생성의 예시를 들 때 정원을 정수형으로 입력하지 않아 생기는 오류로 인해 400이 떴다면, 그 원인 문구를 수집할 수 있었습니다.) 모두 수집이 가능했던 것과는 대조적으로 500 에러를 따로 내부적으로는 감지할 수 없었습니다. (즉 request가 무엇이었는지 수집할 방법이 없었습니다.) 다만 제 생각에는 500 에러는 어차피 유저가 서버 관리자에게 직접 이러이러한 오류가 있다는 것을 알리면 충분하다고 생각하여, 이렇게 구현해도 딱히 문제가 없을 것 같다고 개인적으로는 생각했었습니다.

기존 DRF의 exception_handler는 500에러에 대해 아무런 메시지도 띄우지 않습니다. 이 과정만 커스텀해서, 500 에러 로그 수집 & 사용자가 확인할 수 있는 메시지 설정 두 과정을 과제로 냈습니다.

여기서 이야기하는 exception은 보통 형윤님 말씀대로, 예측을 하지 못했던 오류이기 때문에, 기존에 Response 등으로 내보내던 4XX 에러들과는 결이 약간 다릅니다.

이미지 첨부해주신 것을 보면 잘 이행해주신 것 같은데, exception_handler 안에서 로깅하는 방법에 대해 어려움을 겪고 계신 건가요?

강제로 500 에러가 나는 api를 요청드린 것은 그냥 확인용일 뿐입니다.

[graviol]

@Jhvictor4 지혁님, 답변 남겨주셔서 감사합니다. 말씀 남겨주신 것을 읽어보니, 제가 exception_handler 안에서 예측하지 못한 상황에 대한 에러 로깅에 어려움을 겪고 있는 것이 맞는 것 같습니다. 이에 대한 reference 혹은 참고할 만한 자료가 있을까요...? (현재 제 경우는 500 에러에 대해 exception_handler을 완전히 무시하고 있는 것 같아 보입니다.)

[Jhvictor4]

@graviol 음 exception handler가 다른 상황에서는 잘 작동하나요?

[graviol]

@graviol 음 exception handler가 다른 상황에서는 잘 작동하나요?

기본적으로 원래의 장고 기본 exception handler을 가져와서 거기서 로그를 수집하는 형태로 구현하였기 때문에 다른 상황에서는 작동하는 것 같습니다. 그렇지만 500번 에러는 무슨 이유인지 아예 체크를 못 하는 것 같네요.

[graviol]

해결하였습니다. : )