autocloseable

Is it meaningful for AutoCloseable's close method to throw an exception? How should this be handled?

删除回忆录丶 提交于 2020-01-11 10:04:29
问题 In C#, it is considered bad practice to throw exceptions in the Dispose method of an IDisposable . By contrast, in java the close method of AutoCloseable allows any Exception whatsoever to be thrown and forces the caller to handle it somehow. But what is the caller reasonably expected to do if this happens? This suggests that the attempt to close the resource failed somehow. So does the user have to try to close the resource again before continuing, perhaps with some sort of exponential

In Java, how to check that AutoCloseable.close() has been called?

五迷三道 提交于 2019-12-20 09:48:47
问题 I am authoring a java library. Some of the classes that are meant to be used by library users, hold native system resources (over JNI). I'd like to ensure that the user "disposes" these objects, as they are heavy, and in a testsuite they may cause leakage between testcases (for example, I need to ensure TearDown will dispose). For this purpose I made the Java classes implement AutoCloseable, but this doesn't seem to suffice, or I'm not using it correctly: I don't see how to use try-with

Error: trouble processing “java/lang/AutoCloseable.class”

时光毁灭记忆、已成空白 提交于 2019-12-12 04:36:40
问题 When I compile my project, I am getting this error: trouble processing java/lang/AutoCloseable.class Please help me sort this out. 回答1: Try doing Invalidate cache and restart. This should fix if it is only a build issue. 来源: https://stackoverflow.com/questions/43842737/error-trouble-processing-java-lang-autocloseable-class

Why is Cleaner action not invoked?

蹲街弑〆低调 提交于 2019-12-11 17:36:29
问题 This is a follow-up question from this one. Specifically I'm trying to verify correct use of an API which involves calling close() on Java objects holding heavy native resources over JNI. To re-iterate from that question, this is needed in both tests and production, tests because resources leak from one testcase to another and in production because, well, native resources should just be disposed in controlled manner. The code (all such Java objects that I want disposed would extend JPeer):

Why does Apache CloseableHttpResponse not consume the entity on close?

梦想与她 提交于 2019-12-10 23:19:31
问题 Looking at the quick start guide it gives the following code example: CloseableHttpClient httpclient = HttpClients.createDefault(); HttpGet httpGet = new HttpGet("http://targethost/homepage"); CloseableHttpResponse response1 = httpclient.execute(httpGet); // The underlying HTTP connection is still held by the response object // to allow the response content to be streamed directly from the network socket. // In order to ensure correct deallocation of system resources // the user MUST call

Why is BufferedReader not closed when obtaining `Stream<String>` in try-with-resources?

牧云@^-^@ 提交于 2019-12-10 21:27:43
问题 The reader should be closed when a Stream is used in a try-with-resources. Given this: try(Stream<String> lines = new BufferedReader(reader).lines()) { return lines.map(it -> trim ? it.trim() : it) .collect(Collectors.toList()); } ... the reader is not being closed?? This test fails: AtomicBoolean closed = new AtomicBoolean(false); Reader r = new StringReader(" Line1 \n Line2") { @Override public void close() { super.close(); closed.set(true); } }; try(Stream<String> lines = new

Try-With Resource when AutoCloseable is null

对着背影说爱祢 提交于 2019-12-09 07:23:28
问题 How does the try-with feature work for AutoCloseable variables that have been declared null ? I assumed this would lead to a null pointer exception when it attempts to invoke close on the variable, but it runs no problem: try (BufferedReader br = null){ System.out.println("Test"); } catch (IOException e){ e.printStackTrace(); } 回答1: The Java Language Specification specifies that it is closed only if non-null, in section 14.20.3. try-with-resources: A resource is closed only if it initialized

JDK1.7中新增自动释放资源接口AutoCloseable

大兔子大兔子 提交于 2019-12-07 11:59:41
新增了try-with-resource 异常声明 在JDK7中只要实现了AutoCloseable或Closeable接口的类或接口,都可以使用try-with-resource来实现异常处理和资源关闭 异常抛出顺序。在Java se 7中的try-with-resource机制中异常的抛出顺序与Java se 7以前的版本有一点不一样。 是先声明的资源后关闭 JDK7以前如果rd.readLine()与rd.close()(在finally块中)都抛出异常则只会抛出finally块中的异常,不会抛出rd.readLine();中的异常。这样经常会导致得到的异常信息不是调用程序想要得到的。 JDK7及以后版本中如果采用try-with-resource机制,如果在try-with-resource声明中抛出异(可能是文件无法打或都文件无法关闭)同时rd.readLine();也势出异常,则只会势出rd.readLine()的异常。 public class Main { //声明资源时要分析好资源关闭顺序,先声明的后关闭 //在try-with-resource中也可以有catch与finally块。 //只是catch与finally块是在处理完try-with-resource后才会执行。 public static void main(String[] args) {

Why can a use block not safely initialize a var?

扶醉桌前 提交于 2019-12-07 09:00:27
问题 Why does this give a compile error? val autoClosable = MyAutoClosable() var myVar: MyType autoClosable.use { myVar= it.foo() } println(myVar) // Error: Variable 'myVar' must be initialized Maybe the compiler just sees { myVar= it.foo() } as a function that is passed to another function and has no knowledge about when or even if it will be executed? But since use is not just a function but Kotlin's replacement for Java's try-with-resource, some special knowledge about it would be appropriate,

Why can a use block not safely initialize a var?

邮差的信 提交于 2019-12-05 11:47:56
Why does this give a compile error? val autoClosable = MyAutoClosable() var myVar: MyType autoClosable.use { myVar= it.foo() } println(myVar) // Error: Variable 'myVar' must be initialized Maybe the compiler just sees { myVar= it.foo() } as a function that is passed to another function and has no knowledge about when or even if it will be executed? But since use is not just a function but Kotlin's replacement for Java's try-with-resource, some special knowledge about it would be appropriate, wouldn't it? Right now, I am forced to initialize myVar with some dummy value, which is not in the