예외 투척 vs Optional vs 커스텀 클래스

[robinjoon]

예외적인 상황을 표현하는 방법이 여럿 있는데요, 여러분은 각각의 방법을 어떨 때 사용하나요?

[robinjoon]

커스텀 클래스는 null 이나 비어있음을 표현하는 객체라고 보시면 될 거 같아요

[Libienz]

페어와 비슷한 주제로 토론해본적이 있어요 🤔
체스 미션에서 보드의 특정 위치가 비어있음을 어떻게 표현할 것이냐에서 비슷한 얘기를 해본적 있죠

저는 커스텀 클래스(널 객체, 아무것도 없음을 표현하는 클래스)를 이용하는게 나쁘지 않겠다고 얘기했던 적이 있습니다.

다만 페어의 생각은 저와 달랐어요 다음을 근거로 얘기하더군요 🤔

• 기물들과 함께 커스텀 클래스를 보드에 배치해야 함
• 그렇다면 커스텀 클래스와 기물은 같은 타입으로써 다루어질 수 있어야 함
• 아무것도 없다는 의미의 커스텀 클래스 또한 기물을 상속해야하는 것
• 다만 널 객체가 기물을 상속한다는 것 자체가 모순적인 표현
• 또한 우리가 다형성을 이용하여 기물들을 다룰 때 나이트든 폰이든 널객체든 똑같은 타입으로 취급한다
• 클라이언트 측에서는 널객체를 다룰때 기물다운 행동을 기대하지만 사실 널객체는 예외적인 상황
• 널객체는 의도대로 동작하지 않을 수 있고 이는 혼란을 초래할 수 있다.

저는 결국 설득되어서 예외적인 상황 (throw)로 처리하도록 했는데 막상 보니 커스텀 클래스(널객체)이용하신 분들 꽤나 많더라고요

이러한 생각도 있구나 생각해보시라고 페어와의 이야기 공유드립니다 👍

[leegwichan]

예외 투척

• "해당 일이 진행됨"을 담당하는 메서드인데, 진행할 객체가 없는 경우
  • ex) move(Position start, Position end)를 하는데 start에 기물이 없는 경우

Optional

• 해당 객체가 있을 수도 없을 수도 있는 경우
  • ex) findPiece(Position position)에 해당 기물이 없는 경우 Optional<Piece>로 반환
• 그 중에서도 Optional을 반환하는 메서드를 사용하는 클라이언트에서, 반환 값이 null인지 아닌지에 따라 처리가 달라지는 경우

커스텀 클래스

• 해당 객체가 있을 수도 없을 수도 있는 경우
  • ex) 위와 findPiece(Position position)에 해당 기물이 없는 경우 Optional<Piece>로 반환
• 그 중에서도 메서드를 사용하는 클라이언트에서, 일관적으로 처리를 해줄 수 있는 경우

Optional vs 커스텀 클래스

관점의 차이

위의 말 중에서 "일관적"이라는 표현이 모호할 수 있는데, 이거는 생각하기 나름이라고 생각해.
ex1) 각 기물들을 출력하는데, '기물이 있는 것을 출력하는 것'과 '기물이 없는 것을 출력하는 것'을 동일한 출력이라고 생각한다면 null 객체를 사용
ex2) 각 기물들을 출력하는데, '기물이 없는 것'을 '기물이 있는 것을 출력하는 것'과 구분되는 예외적인 상황이라고 생각한다면, Optional을 사용

대신, null 객체를 추가했더니 해당 null객체의 의미가 모호해진다면, Optional을 고려해볼 것 같아.

구현의 차이

두 관점이 주관적인 차이가 될 수 있다면, 구현 상 편한 것을 사용하는 것이 좋다고 생각해
Optional이 제공하는 메서드, null 객체를 사용했을 때 장점들을 고려해보면서 코드가 읽기 쉬운 쪽으로 하지 않을까?

[seokmyungham]

예외 투척 vs Optional vs 커스텀 클래스

의도와 상황에 따라 많이 달라지는 것 같아요.

일단 DB로부터 특정 값을 조회해서 메서드 반환하는 경우, 거의 모든 상황에서 Optional을 사용해서 null 체크를 하는 편입니다.
객체 지향의 특성으로 인해 stack tarce를 봐도 어디서 NPE가 발생한건지 추적하는게 쉽지 않습니다.
Optional로 감싸면서 이 객체가 null일 수도 있다는 의도를 다른 개발자들에게 명시하고 처리할 수 있는 점이 장점이라고 생각합니다.

Optional을 사용하지 않고 바로 예외를 던지는 경우는 설계 의도에 따라 달라질 수 있다고 생각하는데

이번 체스 미션의 경우
저와 페어는 Map에 모든 포지션을 저장하는 것이 아닌, 현재 존재하는 위치와 기물만 저장하도록 설계했기 때문에 커스텀 클래스는 고려하지 않았습니다.

그런데 여기서 조회를 원하는 위치에는 기물이 "반드시 존재"해야 하는 것이 설계 의도기 때문에
조회한 기물이 존재하지 않는 경우는 정말 "예외" 적인 상황에 가깝다고 볼 수 있습니다.

그래서 이 데이터가 비어있을 수도 있다라는 여지를 주는 Optional 을 사용하지 않고 예외를 바로 던지도록 구현하였고,
예외를 바로 던짐으로써 현재 프로젝트 및 데이터의 정합성이 심각하게 잘못된 상태라는 의도를 나타낼 수 있다고 생각합니다.

의견을 정리해보면 null이 선택 사항이 될 여지가 있는 경우 Optinal,
설계 의도에 매우 벗어났을 경우 상황에 따라 바로 예외를 던지는 선택을 하는 것 같습니다 😄