사실 이 문제에 대해 너무 걱정할 필요는 없습니다. JDK1.7의 try-with-resources에 의존할 필요가 없습니다. 먼저 리소스를 닫고 try 블록에 넣으세요. 분명히 문제가 있을 것입니다. 리소스가 닫히지 않을 수도 있습니다. 그러므로 자원 폐쇄는 마침내에 위치해야 합니다. finally 블록의 close 리소스에 대해서는 IOE이 추가로 도입될 예정인데, 이는 불가피합니다. 현재 (내가 본 바로는) 대부분의 코드에서 IOE 캡처 후 최대 하나의 로그가 기록되며 noop인 경우가 더 많습니다. 즉, 아니요. 아무것도 하지 마세요 . 닫는 동안 IOE가 발생할 확률은 매우 낮습니다. 이는 운영 체제 수준의 오류이므로 이를 무시하는 것이 결국 리소스 닫힘 오류로 인해 실행을 중지할 수 없습니다. 게다가 이 IOE를 꼭 붙잡아야 한다면 어떻게 할 수 있겠습니까?
finally 블록에 try-catch를 도입하고 싶지 않다면 guava의 닫는 메소드를 본 적이 있습니다. closeQuietly()라는 도구 메소드를 작성하세요. 시끄럽지도 않고 좋습니다.
사실 이 문제에 대해 너무 걱정할 필요는 없습니다. JDK1.7의 try-with-resources에 의존할 필요가 없습니다.
먼저 리소스를 닫고 try 블록에 넣으세요. 분명히 문제가 있을 것입니다. 리소스가 닫히지 않을 수도 있습니다.
그러므로 자원 폐쇄는 마침내에 위치해야 합니다.
finally 블록의 close 리소스에 대해서는
IOE
이 추가로 도입될 예정인데, 이는 불가피합니다.현재 (내가 본 바로는) 대부분의 코드에서
IOE
캡처 후 최대 하나의 로그가 기록되며 noop인 경우가 더 많습니다. 즉, 아니요. 아무것도 하지 마세요 .닫는 동안 IOE가 발생할 확률은 매우 낮습니다. 이는 운영 체제 수준의 오류이므로 이를 무시하는 것이 결국 리소스 닫힘 오류로 인해 실행을 중지할 수 없습니다. 게다가 이 IOE를 꼭 붙잡아야 한다면 어떻게 할 수 있겠습니까?
finally 블록에 try-catch를 도입하고 싶지 않다면 guava의 닫는 메소드를 본 적이 있습니다. closeQuietly()라는 도구 메소드를 작성하세요. 시끄럽지도 않고 좋습니다.
초대해 주셔서 감사합니다
으아악Java7의 리소스를 사용해 볼 수도 있습니다
참고자료
많은 코드를 절약할 수 있는 향상된 라이브러리인 Amway, Lombok을 방문해 보세요.
@CleanUp
추가하신 질문 역시 IDE 문제로 인한 답변입니다.
또한 AutoCloseable 및 Closeable 인터페이스를 구현하는 리소스의 경우 try-with-resources 구조를 사용하는 것이 가장 좋습니다.
코드를 예로 들면 일부 코드가 생략되었습니다
으아악JDK1.7 이전의 예외 포착 구조를 사용하면 io 예외가 readline과 close 모두에서 발생한다고 가정하고, close 예외만 포착할 수 있으며 readline 예외는 억제됩니다. (마지막으로 코드를 실행해야 하니까)
또 다른 질문입니다. try-with-resources에서 리소스 AutoCloseable의 닫기 메서드는 언제 실행되나요?
try 코드 블록이 실행된 후에 실행되므로(실험 코드는 여기에 게시되지 않음) try-with-resources 구조를 사용하면 리소스가 닫힐 때까지 catch 블록과 finally 블록이 실행되지 않습니다. .