문법 사용 여부보다 try-finally 대비 안전성과 suppressed exception이 왜 생겼는지를 같이 보는지 가르려는 질문이다.
try-with-resources는 AutoCloseable을 구현한 객체를 try 괄호에 선언하면 블록을 빠져나갈 때 close를 자동 호출한다. 여러 자원을 동시에 잡으면 선언의 역순으로 정리되므로 수동 finally보다 누락이 적고 코드가 짧아진다. 본문에서 예외가 먼저 나고 close에서도 예외가 발생하면 close 예외를 suppressed로 보관해 원인 예외를 그대로 위로 던지고, 두 예외를 함께 추적할 수 있게 해준다. 정리 안정성과 디버깅 품질을 한 문법으로 챙길 수 있다는 게 핵심이다.
장수명 프로세스에서 자원 누수로 메모리가 천천히 차오른 경험이 있다면 try-with-resources 도입 효과와 연결할 수 있다
suppressed 예외 로그를 따라가서 close 단계의 숨은 원인을 잡아본 적이 있다면 디버깅 사례로 말할 수 있다
커스텀 리소스를 AutoCloseable로 설계해 본 경험이 있다면 close 멱등성·예외 정책 판단으로 엮을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.