404 Not Found으로 전력투구

 

JPA에서 서비스에서 레파지토리를 호출하고 레파지토리가 엔티티를 호출해서 db에 조회값을 가져온다

 

일반적인 흐름인데 404 익셉션이 발목을 잡았다.

 

뭔가 개인적인 욕심은 전역핸들러가 최종 결과물을 받아 dto 안에 객체가 비었으면 404를 아니라면 200으로

 

보내는 무언가 그럴듯한 코드를 짜고 싶었는데 시간도 촉박하고 그럴만한 능력이 조금 안되기도하고

 

Optional를 써서 익셉션을 내기로 결정했다.

 

 

초기 코드는 아래와 같았다

return Optional.ofNullable(
userRepository.getUserInfo(booleanBuilder)).orElseThrow(() ->
new BusinessExcption(ErrorCode.NOTFOUNDDATA)
);

 

헌데 쓰고 나니 이러면 성능 이슈가 있지않나? 라는 생각을 했다

 

1. Optional 자체가 코스트가 비싸다.

 

2. orElseThrow은 isPresent()의 메서드를 내부적으로 호출하기 때문에 추가적인 비용이 또 든다

(100원짜리 물건샀는데 부가세로 30원 더 내라고 하면 빡치잖아요..)

 

3. 람다 표현식은 실행될떄 마다 새로운 익명 클래스 인스턴스를 만들기 떄문에 오버헤드가 발생한다.

 

 

그런데 늘 프로그래밍 관점에서 일정 부분의 trade-off가 있는것이 이렇게 씀으로써 얻을 수 있는 이점이 있다.

 

1. 가독성이 좋아진다. 

 

2. 유지 보수성이 좋다

 

 

즉 장점 1,2번을 포기하고 오버헤드를 줄이고자 한다면 우리는 내부 동작을 어느정도 이해하기 떄문에 몇가지 대안을 만들 수 있다.

 

대안1. Optional을 쓰되 isPresent을 직접 호출하고 람다 표현식을 제거한다. 

Optional<userInfo> userInfoOpt = Optional.ofNullable(memberRepository.getUserInfo(booleanBuilder));
if (userInfoOpt.isPresent()) {
    return userInfoOpt.get();
} else {
    throw new BusinessException(Error.NOTFOUNDDATA);
}

 

 

대안2. Optional을 쓰지 않고 null 비교를 직접한다.

userInfo userInfo = memberepository.getUserInfo(booleanBuilder);
if (userInfo != null) {
    return userInfo;
} else {
    throw new BusinessException(ErrorCode.NOTFOUNDDATA);
}

 

 

물론 무엇을 쓰는지는 서비스의 호출 횟수,서버의 규모 등등 고려할 상황이 많지만 코드 블럭에 든 3가지의 경우가 어떤 경우에 쓰이는지만

 

알면 내 환경에 적용하여 충분히 작성할 수 있을것이다.

 

 

+ 참조 1. 아래는 옵셔널을 만든 개발자가 스택오버플로우에 남긴 글이다 총평하자면 자신이 그걸 만든 의도와는 사람들이 다르게 쓰고 있다. 그래서 올바르게 쓰는 방법은 이렇고 의도는 이렇다 라는 글이다

 

https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555

Should Java 8 getters return optional type?

 

구글 번역 켜놓고 읽어보면 예상외로 재밌다 ㅋㅋㅋ 

 

+ 참조 2. 옵셔널이 왜 비싼가는 벤치마크의 결과가 처참하다. 아래 링크를 보면 실제 글 저자가 여러가지 방법으로 실제 성능 비교를 

해보는데 옵셔널은 성적이 처참하다 못해 이정도라고? 라고 생각이 들 정도로 황당하니 한번 보자 왜 그런지에 대한 이유도 친절하게 알려준다.

https://pkolaczk.github.io/overhead-of-optional/

Overhead of Returning Optional Values in Java and Rust | Piotr Kołaczkowski

 

도움이 되었길!