오늘 TIL 3줄 요약

• 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야한다.

• 비즈니스 논리와 오류처리가 각 분리된 코드로 독립성을 유지한다면 깨끗한코드 작성과 유지보수성이 향상된다.

• null을 전달/반환하지마라

TIL (Today I Learned) 날짜

2022.03.04

오늘 읽은 범위

7장. 오류처리

책에서 기억하고 싶은 내용을 써보세요.

• try-catch-finally 작성으로하여금 트랜젝션 본지을 유지하기 쉬워진다. - p.132

• But, 모든 예외를 열거하는 방식이 안정화 요소가 아니다.

• 예외에 의미를 제공하라

  • 오류 메세지에 정보를 담아 예외를 함께 던져라. ( 실패 연산의 이름과 유형 )

• 호출자를 고려해 예외클래스를 정의하라 - p.137

  • 외부 API를 사용하는 경우 감싸기 기법이 최선이다.

    
    -> 외부 라이브러리와 프로그램 사이의 의존성이 크게 줄어든다.

• null을 반환하지 마라 - p.139

  • null확인이 누락된 문제라 말하기 쉽다. 하지만 실상은 null확인이 너무 많아 문제다. 메서드에서 null을 반환하고픈 유혹이 든다면 그대신 예외를 던지거나 특수사례객체를 반환한다.
    -> 많은 경우에 특수 사례 객체가 손쉬운 해결책이다.

• null을 전달하지마라 - p.139

  • 메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다.

  • 정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피해라.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 가장 최선의 예외처리는 무엇인지, 읽는 양은 많지 않았지만 생각의 물꼬를 오래 태웠다.

• 책의 내용이 긴 챕터는 아니었으나 이해하는데 좀 더뎠던 챕터가 되었다. 아무래도 용어나 현상에대해 무지함에서 오는 이해의 시간이었다랄까...

• 모든 시스템들이 처음부터 온전한 데이터를 갖는다 100% 장담할 수 없기에 프로그램에서 고려해야할 것들이 많다. 언제 어디서 예외가 발생할지 몰라 시간이 지날수록 더러워져가던 내 코드가 생각이 났다. 최대한 정리된, 일관성 있는 코드의 형태를 유지하고자 노력했던 내 시간들..

• 예외처리 항상 염두 할 것, 코드를 짜면서 다시한번 생각해 볼 것

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• Invalid Argument Exception (이외 튻수 주 예외들을 알아둘것)

• assert문

• 아직 해결하지못한 궁금증,
  (어떤이가 처리한 코드를 보았다. 채을 읽기 전에도 무언가 언짢은 코드였다.)

  • 어느 method의 return이 map <String,Object>로, 해당 method는 어떤 특정 key가 있을수도 없을수도 있던 코드가 발생시키고 있었다.

  • 또한, 작성한이는 return된 값의 해당 key의 value값을 String으로 변환하여 사용하고있었으며, 이 key에대한 NullpointException을 피하기위햐여 (String)으로 type casting을 하고있는코드를보면서 과연 이것의 처리방향이 맞는지 의문이었다.

  • 해당 Key는 확장자 검사 코드였는데 해당키 값을 "upload_error"라는 key로 너무 포괄적으로작성한점, ( -> 오류메세지를 정확히 할것 / 매우 언짢았고, 책을 읽고서는 불편함에 100% 확신을 하였다.)