티스토리 뷰
Item09는 try-finally 보다 try-with-resources를 사용하라 말한다
당연하다, try-finally로 자원 반환을 직접할 필요가 없다
한 때는 try-finally로 자원을 직접 닫고 메서드를 끝내던 시기가 있었다
try-finally로 명시해 자원을 반환하던 이는 지겨운 반복 작업에서 벗어나고자 try-with-resources를 개발했을 것이다
그렇다면 자바를 사용하는 우리와 같은 입장에서는 무조건 쓰는 것이 좋다
다른 API는 트레이드오프라도 있지만 try-with-resources 만큼은 절대적이다 그냥 쓰자
써야할 이유를 굳이 더 붙이자면 try-finally 사용 시에 try 절에서 잘못된 파일을 열어 예외가 발생했는데
finally 절에서 파일을 닫기 위해 file.close() 호출 시 잘못된 파일을 닫는 것이므로 여기서도 예외가 발생한다
이 상황에서 문제 상황의 핵심이 아닌 두번째 예외 때문에 예외의 핵심이었던 첫번째 예외가 가려진다
이런 미묘한 차이는 책을 보고 있을 때나 의식하지, 평상 시라면 어 이게 왜 터져 하고 한참 디버깅할 문제다
또한 여러 자원 사용 시 try 블록이 점점 깊어지고 콜백 지옥과 같은 아래의 아도겐 모양새를 볼 수 있게 된다
심지어 아래의 아도겐은 가독성이 좋은 것이다
자바에서 지옥의 9~10중 중첩문을 보게 된다면 리팩토링도 생각나지 않을 정도로 아찔해진다
H/W나 S/W 모두 시간이 흐르면서 엄청난 발전을 이루어냈다
그렇기 때문에 갓 입문한 초보 개발자는 왜 쓰는지도 모르고 이게 왜 좋은지도 모르고 사용만 할 줄 알게 된다
나 역시 예외는 아니었고 try-finally 로 뭘 하는 건지도 잘 모르는 상태인데
try-with-resources라는 건 또 뭐야하고 넘어갔지만 이제는 좀 이해가 되는 것 같다
어떤 것이든 거인의 어깨를 밟고 올라온다
따라서 try-with-resources를 사용해야 할 이유는 간단하다, try-finally의 어깨를 밟고 올라온 놈이기 때문이다
이 간단한 원칙만 생각하면 생각보다 개발이 재밌어진다
난 특히 spring-redis-cache와 spring-data-jpa를 사용하면서 S/W의 엄청난 발전이 있음을 느꼈다
@Cacheable 애노테이션에 설정 몇개 붙이는 것만으로도 캐시를 박아준다던가
@Entity, @Column 등의 애노테이션을 사용해 프로그램을 작성하면 쿼리가 날라간다던가 하는 점에 경이로웠다
그렇기에 대강 API 사용법만 알고 무지성 코딩을 하더라도 프로그램이 그럭저럭 돌아갈 수 있다
대부분 성능 상 필요에 의해 저수준을 건드려야 할 작업이 아니라면 고수준 메서드, API를 사용하자
우리와 같은 길을 걷던 수 많은 사람이 반복 작업에 빡쳐서 지루하고 까다롭고 이해하기 힘든 저수준 작업을 거의 추상화해놨다
단 그로 인해 추상화 수준이 점점 높아지면서 단순하게 메서드 이름만으로 행동을 짐작하게 되고
그 안에서 어떤 식으로 동작하는 지를 모르게 되기도 한다
너무 높은 추상화에 의해 구현과의 거리가 지나치게 멀어진 것이다
개발자의 레벨은 알고 쓰느냐 모르고 쓰느냐에서부터 시작해 얼마나 깊이, 넓게 아는 지가 가르는 것 같다
Item09를 보다가 거의 일기를 써버렸다
'Java > Effective Java' 카테고리의 다른 글
[Item11] @EqualsAndHashCode (2) | 2022.02.19 |
---|---|
[Item10] equals 일반 규약을 깨보자 (0) | 2022.02.19 |
[Item08] finalizer, cleaner를 알아보지 말자 (0) | 2022.02.14 |
[Item07] 최고 JVM아 고맙다 (0) | 2022.02.12 |
[Item06] 재사용으로 성능 향상 시켜보자 (0) | 2022.02.10 |