try-with-resource에 지역 변수가 필요한 이유는 무엇입니까?
내 질문과 관련하여 java.util.concurrent.locks.Lock에 대한 AutoCloseable 래퍼의 위험은 무엇입니까? , 왜 trh try-with-resource
에 명명 된 지역 변수 가 필요한지 궁금 합니다.
내 현재 사용량은 다음과 같습니다.
try (AutoCloseableReentrantReadWiteLock.Lock l = _lock.writeLock()) {
// do something
}
이 변수 l
는 try 블록 내에서 사용되지 않으며 네임 스페이스 만 오염시킵니다. 내가 기억할 수있는 바에 따르면 유사한 C#
using
문에는 지역 이름 변수가 필요하지 않습니다.
try 블록의 끝에서 닫히는 익명 로컬 변수로 다음을 지원할 수없는 이유가 있습니까?
try (_lock.writeLock()) {
// do something
}
@McDowell의 댓글에있는 링크 는 try-with-resources 문을 도입 한 Java 기술 사양 을 이끌었던 Joe Darcy 의 블로그 게시물 댓글 에서 정답을 보여줍니다 .
JDK 7로 돌아가서 우리는 메서드 호출을 포함하여 리소스에 일반 표현식을 사용할 수 있도록 허용하는 try-with-resources 구성으로 시작했습니다. 그러나 초기 초안 검토 ( http://jcp.org/aboutJava/communityprocess/edr/jsr334/index.html ) 에서 찾은 전문가 그룹 은
"[try-with-resources statemenbt에 대한] 향후 가능한 변경은 일반 표현식으로 지정 될 자원에 대한 지원을 중단하는 것입니다. 일반 표현식을 자원으로 사용할 수 있도록 허용하면 사소한 사양 및 구현 복잡성이 발생합니다. 제한된 표현식 식별자가 될 수 있거나 PrimaryNoNewArray가 충분할 수 있습니다. 단지 식별자를 허용하는 더 엄격한 제한조차도 훨씬 낮은 한계 구현에서 완전한 표현을 허용하는 거의 모든 추가 유틸리티를 제공 할 수 있습니다. 사양 영향. "
JDK 7이 끝날 무렵 우리가 원했던 것은 리소스 또는 기존의 최종 / 효과적인 최종 변수에 대한 새로운 변수 선언이었습니다. 우리는 7에서 전자를 제공 할 시간이있었습니다. 9에서는 후자도 제공합니다.
그들이 고려한 사용 사례 중 대부분은 블록 내부의 리소스에 액세스해야합니다 (예 : 파일 열기-파일 읽기 / 쓰기-파일 닫기). 지역 변수가 사용되지 않는 사용 사례가 많다고 생각했다면이 설계 결정을 내리지 않았을 것입니다.
Lock이 자동으로 닫힐 수없는 이유에 관해서는 Doug Lea가 구문 문제에 너무 관심이 없다고 생각하며 어려운 문제를 해결하는 데 집중합니다. 다른 사람들은 항상 그의 유틸리티 위에 구문 설탕을 추가 할 수 있습니다.
기대하면 try-with-resource는 아마도 유행에서 벗어나 람다로 대체 될 것입니다. 예를 들면
lock.withLock( ()->{ execute-while-holding-the-lock; } );
내가 원하지 않는 한, 그 이유는 try-with-resources가 폐기되어야하는 항목에 대한 작업을 위해 엄격히 의도된다는 것입니다. 블록 내부에있는 동안 해당 변수로 무언가를 할 것으로 예상하기 때문에 명명 된 변수가 필요합니다. 컴파일러가 "실제로 리소스를 사용할 계획이 없는데 왜 try-with-resources를하는 거죠?"라고 말하는 것과 같습니다.
이제 여러분과 저는 우리가 실제로 리소스를 사용하고 싶지 않다는 것을 잘 알고 있습니다. 오히려 우리가 작업을 마쳤을 때 닫혀 있는지 확인하여 개발자가 시스템을 잠그지 않도록합니다. 그러나 많은 것들이 그렇듯이 그들은 디자인 결정을 내려야했고 소수에 속했기 때문에 우리는 기능을 얻지 못했습니다.
지역 변수를 사용할 수 없다는 것이 try-with-resource의 트리거라고 생각합니다.
Java 1.7 이전에는 다음과 같이 작성해야했습니다.
InputStream in = null;
try {
in = ....;
} finally {
if (in != null) {
in.close();
}
}
여기에는 두 가지 단점이 있습니다.
finally
블록은 성가 시며 각 닫는 리소스에 대해 null로부터 안전해야합니다.- 블록에서 액세스 할 수 있도록 블록 외부의 리소스를 선언해야합니다
finally
. 따라서 우리는 나쁜 습관 인 변수에 접근 할 수있는 범위를 확대합니다.
Try-with-resource 구문은 두 가지 문제를 모두 해결합니다.
finally
블록은 전혀 필요하지 않습니다.- 자원 변수는
try
블록에서만 액세스 할 수 있습니다. 즉, 알려야하는 위치입니다.
이것이 닫을 수있는 리소스가 로컬이어야하는 이유입니다. 그렇지 않으면 try-with-resource 구문의 주요 단점 중 하나는 "비활성화"입니다.
참조 URL : https://stackoverflow.com/questions/16588843/why-does-try-with-resource-require-a-local-variable
'developer tip' 카테고리의 다른 글
express.json 대 bodyParser.json (0) | 2020.12.27 |
---|---|
Java Enum 및 Switch 문-기본 케이스? (0) | 2020.12.27 |
Git : 한 번에 여러 브랜치를 리베이스하는 방법 (동일한 기본 커밋으로)? (0) | 2020.12.26 |
Android 애플리케이션 클래스 수명주기 (0) | 2020.12.26 |
Android 앱을 MySQL 데이터베이스에 연결하는 방법은 무엇입니까? (0) | 2020.12.26 |