티스토리 뷰

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중 중첩문을 보게 된다면 리팩토링도 생각나지 않을 정도로 아찔해진다

https://adrianalonso.es/desarrollo-web/apis/trabajando-con-promises-pagination-promise-chain/

 

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를 보다가 거의 일기를 써버렸다

댓글
링크
글 보관함
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Total
Today
Yesterday