오늘 TIL 3줄 요약

• 오류 발생은 프로그래머 책임!

• 포괄적인 오류가 아닌 구체적으로 오류 설정!

• null은 필요악!

TIL (Today I Learned) 날짜

2022.03.03(목) ~ 2022.03.04(금)

오늘 읽은 범위

~ 7장. 오류 처리

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

• 뭔가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다.(130p)

• 예외에 의미를 제공하라.(135p)

• 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.(135p)

• null을 반환하지 마라.(138p)

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

• 이번 챕터인 오류처리는 사실상 프로그래밍을 할 때 빠뜨려도 크게 문제가 되지 않는 부분이라고 생각한다. 실제로 API를 만들거나 컴포넌트를 만들 때 예외처리 대신 예외 코드를 반환한다거나 이런 코드를 많이 봤는데 프로그램이 동작하는데에는 큰 무리가 없었다.

  하지만 어떤 오류가 생겼을때 그 처리방법이 깔끔하지 않아 안정성이 많이 떨어지는 걸 보았다.

• 개인적으로는 간단한 API 하나를 만들더라도 오류에 따라서 HTTP STATUS를 적절하게 세팅하려고 하는 편인데, 보통은 200에 오류 코드를 심어서 API를 만드는 것을 보면 고치고 싶은 충동이 든다.

  이처럼 오류처리를 잘못하고 있는 프로그래머들이 많은데 꼭 이 챕터를 보고 느끼는바가 있었으면 좋겠다.

• 사실 그동안 작업하면서 오류 처리는 꼼꼼하게 살펴보지 않으면 넘어갈 수 있는 부분인데 (나도 이전에는 그랬었고) 어느 순간부터는 오류 처리가 정말 중요하다고 생각되어

  꼭 그에 맞는 오류 처리를 하려고 노력하고 있다. 이렇게 사소한 차이 하나가 모여 좋은 프로그래머를 만들고 좋은 제품을 만들기 때문에

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

• 어떤 면에서 try 블록은 트랜잭션과 비슷하다. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.

  • try블록이 트랜잭션과 같다는 말이 어떤 의미일까.. 곱씹어 봐야겠다

• OCP(Open Closed Pricinple): 확장에 대해 열려있어야 하고, 수정에 대해서는 닫혀있어야 한다는 프로그래밍 원칙

  • 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다는 말인데, 어떤 느낌인지는 알겠지만 실제로 사용하기엔 아직 조금 더 이해가 필요하다.

• 특수사례패턴(Special Case Pattern): 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식

오늘 읽은 다른사람의 TIL

• profitzoo11님의 TIL(https://nomadcoders.co/community/thread/3295)

• dbfla4618님의 TIL(https://nomadcoders.co/community/thread/3285)

• codingcat00님의 TIL(https://nomadcoders.co/community/thread/3286)