최근 학습을 하며 알게 된 내용에 대한 개인적인 생각입니다.
Checked exception은 OCP 위반
최근 본 영상에서 "Checked exception은 OCP(Open Closed Principle)를 위반한 것이다."라는 내용을 접했다. 내용인 즉 하위 의존성에서 Checked exception이 추가되면 변경사항이 전파되기 때문에 변경에 닫혀있지 않다는 것이다.
이전까지 Checked exception과 OCP와의 관계를 생각해보지 못했는데 굉장히 좋은 인사이트라 개인적으로 좀 더 찾아보며 내린 나름의 결과는 "아니다"이다.
Checked exception
Java was a much safer language than most of its predecessors: all behaviour defined and consistent across all platforms, and many features intended to prevent crashes, unexpected behaviour, or fragile coding.
Stackoverflow — author gidds
Java에서 예외는 Checked exception과 Unchecked exception으로 나뉠 수 있다. 스택오버플로우의 gidds의 말을 참고하면, Java는 Checked exception을 통해 멀티 플랫폼 환경에서도 일관되며 취약한 코드 작성을 방지하며 안정적인 언어로 발전되었다고 한다. 즉, "안전성"을 위한 언어 시스템인 것이다.
확장성과 안전성
소프트웨어 개발은 변경의 예술이다. 특히 웹 서비스 분야는 빠르게 증가하는 경쟁사, 그리고 시시각각 변화하는 사회 흐름과 사용자의 요구사항을 반영하기 위해서 하루에도 수십 번의 배포가 이뤄진다. 즉 확장성은 서비스의 생존과도 연관이 있다.
하지만 그 앞에 당연히 만족해야 하는 것이 있는데, 그것은 안전성이다. 서비스가 안정적으로 운영이 되지 않는다면 아무리 좋은 기능과 사용자의 요구사항을 만족해도 신뢰성이 무너지며 사용자는 이탈하게 된다.
즉, 안전성을 위한 장치로 인해 변경이 되었다고 "변경에 닫혀있다"라고 표현하기는 어렵다는 것이 내 의견이다. 필요한 변경에 의해 변경되는 것은 소프트웨어서 당연하다.
그럼에도 불구하고
I'm not happy throwing the baby out with the bathwater
그럼에도 불구하고 코틀린에서는 Checked exception을 제거했다. 하지만 이러한 결정은 개발자들이 Checked exception에 대한 처리가 잘못된 관습을 만들기 때문에 제거한 것이며, 이 의견에 대해서 다른 측에서는 개발자가 잘못 사용한다고 언어적 안전장치를 제거하는 것이 올바른 결정인가?라는 의문을 나타내는 분들도 많은 것 같다. 개인적으론 후자로 개발자는 전문가이며, 잘못된 방식은 고쳐나가야 할 문제라고 생각한다.
참고
'메모' 카테고리의 다른 글
틴타임즈 : 뉴스 10초 요약 회고 (0) | 2023.12.29 |
---|---|
하이버네이트 공식 문서를 읽고 배운 점 (0) | 2023.12.29 |
알림 기능 고찰 🤔 (0) | 2023.12.21 |
extends JpaRepository<Cookie, String> (0) | 2023.12.20 |
🚀 데이터베이스 이전 대작전! 📊 클라우드로의 여정 🌐 (0) | 2023.12.15 |