Golang Convention에서 Error Wrapping과 Opaque Error처리가 서로 충돌이 있는것 같아어떻게 정리를 해야할지를 추가로 정리해봅니다. 1. Opaque Error (불투명한 오류)"Opaque Error"는 오류 발생 지점에 대한 구체적인 정보가 부족하고, 오직 메시지 문자열만으로 전달되는 형태의 오류를 의미합니다. 이는 오류의 원인을 파악하기 어렵게 하며, 코드 디버깅을 어렵게 만드는 주요 원인입니다. 이 관점에서 살펴보면, 원래 예시 코드에서 문제가 되는 부분은 오류의 맥락이 포함되지 않아서, 오류가 어디에서 발생했는지를 쉽게 알 수 없다는 것입니다.func AuthenticateRequest(r *Request) error { err := authenticate(r..

배경현재 프로젝트에서 Error 처리를 일관적이지 못한 방법으로 하고 있다는 생각이 들어서 글을 쓰게 되었습니다.작년의 Golang 초기 사용 시점에는 모두 언어에 대한 이해도가 낮고 MVP 완성을 위해 빠르게 코드를 짰어야 해서 전체적으로 코드를 짠 사람의 코딩 Convention을 따라가게 되었습니다.그때의 Error handling 사용의 형태를 유사하게 활용해 오다 보니 현재까지 같은 문제를 가지고 있는 Error handling을 가져오게 된 것이죠. 그래서 우리의 Error handling은 같은 문제들을 가지고 있습니다. 현재 프로젝트의 에러 처리 방식의 문제점1. 에러 로그의 일관성이 부족합니다.어떤 에러 로그는 최상위 API 실행시에만 몰아서 출력되고,어떤 에러 로그는 최상위 API 실행..