Skip to content

Conversation

@jyeonjyan
Copy link
Member

앞으로 추가하거나, 시간 있으면 수정이 필요해보여요.
query method 반환 값이 이런식으로 되어야하지 않을까 ^^;
의견 부탁드립니다.

@jyeonjyan jyeonjyan requested a review from vumrra July 28, 2025 02:00
@wwwcomcomcomcom
Copy link
Collaborator

제가 go언어를 많이 접해보지 못해서 그런지, 바뀐 코드가 어떤 의미에서 더 좋은 코드인지 잘 이해하지 못했습니다. 어떤 이유에서 바뀐 코드가 개선된 코드인지 설명해 주실 수 있을까요?

@jyeonjyan
Copy link
Member Author

@wwwcomcomcomcom
query 한 result는 DB 에 있을수도 있고 없을 수도 있어서 기본적으로 "nullable" 이 되어야 할 것 같고,
repository 안에서 바로 panic 을 호출하는게 아니라 panic 을 할지 뭘할지는 호출부에서 해야하는 일이 아닌가 싶었어요.

@wwwcomcomcomcom
Copy link
Collaborator

@wwwcomcomcomcom query 한 result는 DB 에 있을수도 있고 없을 수도 있어서 기본적으로 "nullable" 이 되어야 할 것 같고, repository 안에서 바로 panic 을 호출하는게 아니라 panic 을 할지 뭘할지는 호출부에서 해야하는 일이 아닌가 싶었어요.

답변 감사합니다! 예시로 변경된 쿼리가 select 1 이었어서 nullable에 대해 잘 이해하지 못했던것 같습니다.
또, 이번에 go에서 에러처리, panic 관련해서 자주 사용되는 방식을 알아보게되어 도움이 되었습니다. 감사합니다.

@snowykte0426
Copy link
Member

좋은 개선 방향이라고 생각합니다!

Repository 레이어에서 바로 panic
호출하는 것보다 error를 반환해서 호출부에서 상황에 맞게 처리할 수 있도록 하는 것이 코드의 유연성과 테스트 가능성 측면에서도 더 나은 구조인 것 같습니다. 특히 DB 조회 결과가 없는 경우는 예외적인 상황이 아니라 정상적인 비즈니스 케이스일 수 있기 때문에, 이를 panic으로 처리하기보다는 명시적인 에러 반환으로 처리하는 것이 더 적절해 보입니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants