TIL-2023.01.05

오늘 한 것

• "좋은 코드 나쁜 코드" 4장 읽기.

 

---

 

 

좋은 코드 나쁜 코드의 4장에서는 오류에 대해 설명한다.
최근 팀에서도 에러 핸들링에 대한 규칙이 없어서 고민을 하던 나에게 마침 필요한 챕터였다.
오류가 발생하는 케이스를 인지하지 못하고 Null값이 실행 흐름에 흘러들어가게 만들어 NPE를 발생하게 만드는 경우. 버그 또는 악의적인 의도로 비정상적인 유형으로 실행할 때 "", {}, [], 0 같은 기본값을 반환하는 경우. 차라리 Null의 경우가 낫다.
명시적으로 에러가 발생할 수 있음을 표시하지 않고 기본값으로 처리해버리면 디버깅이 힘들었던 경험은 지금까지 많이 해왔고 현재 진행중이다.
명시적인 에러 처리의 장점에 대해 설명하는 부분에서 많이 공감이 됐다.
읽고 난 뒤 소감은 "명시적인 방법으로 오류가 존재함을 알리고 처리하는 것이 바람직하다." 이다.
문제가 무엇 때문에 어디서 발생했는지 확인할 수 있다면 문제를 빠르게 수정하는데 도움이 될 것은 당연하다.

 

---

 

오늘 배운 것

1. 좋은 코드 나쁜 코드 - 4장 오류

요약

• 오류는 크게 2가지 종류가 있다. 시스템이 복구할 수 있는 오류와 없는 오류.
• 에러가 발생하면 신속하게 실패하는 것이 좋고, 에러를 복구할 수 없는 경우에는 요란하게 실패하는 것이 바람직하다.
• 오류를 숨기는 것은 바람직하지 않을 때가 많으며, 오류가 발생했다는 신호를 보내는 것이 바람직하다.
• 오류 전달 기법은 두 가지 범주로 나눌 수 있다.
  • 명시적 방법: 코드 계약의 명확한 부분에 해당. 호출하는 쪽에서 오류가 발생할 수 있음을 인지한다.
  • 암시적 방법: 코드 계약의 세부 조항. 호출하는 쪽에서 오류가 발생할 수 있는지 항상 인지할 수 없다.
• 복구할 수 없는 오류에 대해서는 암시적 오류 전달 기법을 사용해야 한다.
• 잠재적으로 복구할 수 있는 오류에 대해서는
  • 명시적 혹은 암시적 기법 중 어느 것을 사용하는것이 더 좋은지는 개발자 사이에서도 의견이 갈린다.
  • 저자의 의견은 명시적인 기법이 사용되어야 한다고 함. (나도 동의)
• 컴파일러 경고는 코드에 문제가 있음을 알려주므로 주의를 기울이는게 좋다.