☃️ troubleshooting

🍷 왜 금액이 아니라 개수가 나올까?

이번 4주차 미션은 크리스마스 프로모션인데요..!

3주동안의 방식과는 달리 NEW 문제가 출제되어, 비공개 저장소를 제출하는 것으로 변경되었습니다.

주목할만한 조건은 다음의 3가지 정도였습니다.
1. 다양한 요구사항이 여러 군데에 퍼져 있다는 것
2. InputView, OutputView를 사용
3. 할인이 중복!!

이 점을 유의하며 기초 기능 개발을 진행했습니다.
그런데 어김없이 문제가 발생했죠.

• 기대하는 출력 예시는 다음과 같았습니다.

안녕하세요! 우테코 식당 12월 이벤트 플래너입니다.
12월 중 식당 예상 방문 날짜는 언제인가요? (숫자만 입력해 주세요!)
3
주문하실 메뉴를 메뉴와 개수를 알려 주세요. (e.g. 해산물파스타-2,레드와인-1,초코케이크-1)
티본스테이크-1,바비큐립-1,초코케이크-2,제로콜라-1
12월 3일에 우테코 식당에서 받을 이벤트 혜택 미리 보기!
 
<주문 메뉴>
티본스테이크 1개
바비큐립 1개
초코케이크 2개
제로콜라 1개
 
<할인 전 총주문 금액>
142,000원
 
<증정 메뉴>
샴페인 1개
 
<혜택 내역>
크리스마스 디데이 할인: -1,200원
평일 할인: -4,046원
특별 할인: -1,000원
증정 이벤트: -25,000원
 
<총혜택 금액>
-31,246원
 
<할인 후 예상 결제 금액>
135,754원
 
<12월 이벤트 배지>
산타

그러나, 현재 결과 값에 다음의 문제가 있었죠.
1️⃣ 금액이 아닌 개수가 나온다.

• 할인 금액 계산 로직은 정확히 작성했지만, 숫자를 Count하고 금액을 뽑아내는 로직이 한 군데에 작성되었던 것이 문제임을 인지했습니다.
  그러나, 변경 후에도 코드 간의 여러 의존성을 모두 풀어낼 수 없어 해결되지 않았죠🥲

2️⃣ 혜택 내역의 고객에 따른 할인 정보가 없음으로만 출력된다.

• 고객에 따라 달라지는 할인 내역을 출력하는 로직이 비어있어 발생한 오류였습니다.
  그러나, 이 역시 코드 간의 여러 의존성을 모두 풀어내기는 어려웠기에 해결되지 못했습니다😅

3️⃣ 주문 금액 입력 시, 유효한 주문임에도 예기치 않은 종료가 발생한다.

• 이 부분은 예외 메시지의 맨 앞에 각각 번호를 찍고, Break Point를 찍어서 디버깅하는 방식을 사용해 해결했습니다.
  로직이 유효한 주문을 예외로 처리하는 방식으로 잘못 작성되었던 것이 원인이었죠🙉

🐞 디버깅이 뭐지?

• 코드에서 정확히 문제가 발생된 지점이 어느 위치인지 범위를 좁혀나가며 찾아나가는 것!
• 실제로 벌레가 사이에 들어가 하드웨어를 망가뜨려 코드 오류가 발생했던 사건을 유래로 디버깅이라는 이름을 지었다는 말도 있습니다 하하😝

결론 : 명확하게 코드의 로직 오류를 전부 해결하지는 못했지만, 그 과정에서 디버깅을 하는 방법을 연습하고 학습할 수 있었다!

---

🌟 Learning

✍️ 프로젝트의 예기치 못한 예외 처리 및 종료 시 디버깅 하는 법

이번 미션에서의 조건 중 예외 메시지를 통일하는 것이 있었습니다.

---

• 날짜의 경우 : [ERROR] 유효하지 않은 날짜입니다. 다시 입력해 주세요.
• 주문의 경우 : [ERROR] 유효하지 않은 주문입니다. 다시 입력해 주세요.
• 사용자가 잘못된 값을 입력할 경우 IllegalArgumetException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다.
  • Exception이 아닌 IllegalArgumentException, IllegalStateException 등과 같은 명확한 유형을 처리한다.

---

이 조건으로 인해 디버깅을 하는데에 어려움이 있었습니다...🥹
예외 처리가 잘못되어 유효한 주문을 예외로 처리하는 문제였는데, 예외 메시지가 동일하니 어느 지점인지 바로 파악하기 어려웠죠.
그래서 결국 다음의 방법을 택했습니다.

예외 메시지의 맨 앞에 1,2,3,4,... 번호를 붙이고, 각 예외별로 Break point를 찍는다.

인텔리제이에서는 디버깅 모드를 지원하고, 코드 옆을 간단히 클릭하는 것만으로도 break point를 지정할 수 있습니다.

또한 break point가 많아지면 한눈에 관리도 가능해요!

이렇게 break point를 찍어두고, Application을 run했습니다.
예외의 지점을 break point가 보여주기도 하지만, 예외 메시지 앞의 번호로도 지점을 더 빠르게 찾을 수 있었죠!

하지만, 추후에 다른 프로젝트를 진행한다면 이 아쉬움을 다음의 방식으로 해결하고 싶다 생각했어요!!

1️⃣ 예외 메시지는 자세하게, 그리고 지점마다 다르게 출력될 수 있도록 던진다.
2️⃣ 예기치 못한 예외가 발생했을 때에도 프로그램 종료 대신 부분 재시작을 할 수 있도록 로직을 방어한다.

• 그러나 2번에 대해서는 "입력을 계속 끊임없이 받게 되면 스택 오버플로우가 발생할 수 있지 않나?"라는 생각도 합니다.
• 이 부분을 보완하기 위해서는 재입력을 받되, 횟수를 제한한다는 것이 가장 명쾌한 해답일 듯 합니다.

☝️ 결론
디버깅을 하는 방식을 고민하고, 최대한 디버깅을 거치지 않아도 오류가 발생되지 않도록 방어 로직을 잘 작성한다!

---

이번 미션도 이렇게 마무리했습니다.

이번에도 제 생각이 누군가에게 자그마한 도움이 될 수 있기를 바라며 이만 가보도록 할게요!