Develop Reference

try-with-resource vs ordinary code with explicit close()-call [duplicate]

This question already has answers here:
What's the purpose of try-with-resources statements?
(7 answers)
Closed 2 years ago.
I have been looking at code and I have seen try with resources. I have used the standard try-catch statement before and it looks like they do the same thing. So my question is Try With Resources vs Try-Catch what are the differences between those, and which is better.
Here is a try with resources :
objects jar = new objects("brand");
objects can= new objects("brand");
try (FileOutputStream outStream = new FileOutputStream("people.bin")){
ObjectOutputStream stream = new ObjectOutputStream(outStream);
stream.writeObject(jar);
stream.writeObject(can);
stream.close();
} catch(FileNotFoundException e) {
System.out.println("sorry it didn't work out");
} catch(IOException f) {
System.out.println("sorry it didn't work out");
}

The main point of try-with-resources is to make sure resources are closed reliably without possibly losing information.
When you don't use try-with-resources there's a potential pitfall called exception-masking. When code in a try block throws an exception, and the close method in the finally also throws an exception, the exception thrown by the try block gets lost and the exception thrown in the finally gets propagated. This is usually unfortunate, since the exception thrown on close is something unhelpful while the informative one is the one thrown from within the try block. (So instead of seeing the SQLException that tells you which referential integrity constraint was violated, you're shown something like BrokenPipeException where closing the resource failed.)
This exception-masking is an annoying problem that try-with-resources prevents from happening.
As part of making sure exception-masking wouldn't lose important exception information, when try-with-resources was developed they had to decide what to do with the exceptions thrown from the close method.
With try-with-resources, if the try block throws an exception and the close method also throws an exception, then the exception from the close block gets tacked on to the original exception:
... there are situations where two independent exceptions can be thrown in sibling code blocks, in particular in the try block of a try-with-resources statement and the compiler-generated finally block which closes the resource. In these situations, only one of the thrown exceptions can be propagated. In the try-with-resources statement, when there are two such exceptions, the exception originating from the try block is propagated and the exception from the finally block is added to the list of exceptions suppressed by the exception from the try block. As an exception unwinds the stack, it can accumulate multiple suppressed exceptions.
On the other hand if your code completes normally but the resource you're using throws an exception on close, that exception (which would get suppressed if the code in the try block threw anything) gets thrown. That means that if you have some JDBC code where a ResultSet or PreparedStatement is closed by try-with-resources, an exception resulting from some infrastructure glitch when a JDBC object gets closed can be thrown and can rollback an operation that otherwise would have completed successfully.
Without try-with-resources whether the close method exception gets thrown is up to the application code. If it gets thrown in a finally block when the try block throws an exception, the exception from the finally block will mask the other exception. But the developer has the option of catching the exception thrown on close and not propagating it.

You missed something, the finally block. The try-with-resouces will make it something like,
FileOutputStream outStream = null;
try {
outStream = new FileOutputStream("people.bin");
ObjectOutputStream stream = new ObjectOutputStream(outStream);
stream.writeObject(jar);
stream.writeObject(can);
stream.close();
} catch(FileNotFoundException e) {
System.out.println("sorry it didn't work out");
} catch(IOException f) {
System.out.println("sorry it didn't work out");
} finally {
if (outStream != null) {
try {
outStream.close();
} catch (Exception e) {
}
}
}
Which means you really wanted something like (never swallow exceptions),
try (FileOutputStream outStream = new FileOutputStream("people.bin");
ObjectOutputStream stream = new ObjectOutputStream(outStream);) {
stream.writeObject(jar);
stream.writeObject(can);
// stream.close(); // <-- closed by try-with-resources.
} catch(FileNotFoundException e) {
System.out.println("sorry it didn't work out");
e.printStackTrace();
} catch(IOException f) {
System.out.println("sorry it didn't work out");
e.printStackTrace();
}

The only difference is that try-resource is adding automatically resource.close();
as you would do in finally block

Any object (either the class or their superclass) that implements java.lang.AutoCloseable or java.io.Closeable
can only be used in try-with-resource clause.
AutoClosable interface is the parent interface and Closable interface extends the AutoClosable interface.AutoClosable interface has method close which throws Exception while Closable interface has method that throws IOException.
We can also have catch and finally block followed by try-with-resource like ordinary try, catch and finally, but catch and finally block only get executed once the resource declared inside the try-with-resource clause is closed.

Succinctly it is syntactic sugar to support the AutoClosable interface and call the close() method for you for any outcome.

Under what circumstances could closing a stream fail? [duplicate]

This question already has answers here:
Does close ever throw an IOException?
(5 answers)
Closed 7 years ago.
According to many tutorials I've read regarding streams and the like, it is considered good practice to close a Stream not inside the try-block, but inside the finally instead, to ensure it's closing with and without an exception.
Of course, this has to be again surrounded by a try-and-catch again, as .close() can throw an IOException. However, as the Javadoc of under what conditions this might happen ("Throws: IOException - if an I/O error occurs.") is extremely vague, I wondered what, specifically, would have to happen for this exception to be thrown at this place. Below is an example code.
FileInputStream fis = null;
try {
fis = new FileInputStream("C:\\TestFiles\\JapaneseFileNames");
// Do some stuff
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if(fis != null) {
fis.close();
}
} catch(IOException e) {
throw new RuntimeException("Something happened, but what?", e);
}
}

If the stream extends FilterOutputStream, the close() method first calls flush(), which may try some I/O and encounter an IOException, which is thrown to the caller of close(). BufferedOutputStream is the typical case.
If the stream extends FilterOutputStream and is wrapped around another one, calling close() calls close() on the wrapped stream, which behaves as above. new DataOutputStream(new BufferedOutputStream(...)) and new ObjectOutputStream(new BufferedOutputStream(...)) are typical cases.

Does finally completely execute if an exception is thrown within finally block

so I have a bit of code here and I'm not sure entirely how it would react in the event that the reader.close() method throws an exception.
public void someMethod(String s) throws IOException{
BufferedReader reader = Files.newBufferedReader(filePath,cs);
listRWLock.readLock().lock();
try{
//miscellaneous code involving reading
}finally{
reader.close()
listRWLock.readLock().unlock()
}
}
ListRWLock is a ReentrantReadWriteLock. In the event that the reader.close() method throws an exception, would the statement after it fail to execute? I've tried searching for the topic, and while I've gotten something about finally executing in the event of return statements, I haven't managed to find details on what happens if an exception is thrown within the finally block.
Thanks in advance.

Basically, finally clauses are there to ensure proper release of a resource. However, if an exception is thrown inside the finally block, that guarantee goes away.
An issue for which there's no really neat solution is that code in the finally block could itself throw an exception. In this case, the exception in the finally block would be thrown from the exception instead of any exception occurring inside the try block. Since code in the finally block is intended to be "cleanup" code, we could decide to treat exceptions occurring there as secondary, and to put an excplicit catch:
public int readNumber(File f) throws IOException, NumberFormatException {
BufferedReader br = new BufferedReader(new
InputStreamReader(new FileInputStream(f), "ASCII"));
try {
return Integer.parseInt(br.readLine());
} finally {
try { br.close(); } catch (IOException e) {
// possibly log e
}
}
}
Some other things to note about finally blocks:
The same 'overriding' problem that we mentioned with exceptions
occurs when returning a value from a finally block: this would
override any return value that the code in the try block wanted to
return. In practice, returning a value from a finally clause is rare
and not recommended.
Actually exiting the program (either by calling System.exit() or by
causing a fatal error that causes the process to abort: sometimes
referred to informally as a "hotspot" or "Dr Watson" in Windows)
will prevent your finally block from being executed!
There's nothing to stop us nesting try/catch/finally blocks (for
example, putting a try/finally block inside a try/catch block, or
vice versa), and it's not such an uncommon thing to do.

You can do something like this:
try{
//miscellaneous code involving reading
}finally{
handlePossibleException(reader);
listRWLock.readLock().unlock()
}
handlePossibleException(BufferedReader reader) {
try {
if (reader != null) {
reader.close();
}
} catch( Exception e ) {
log.e( "reader.close() Exception: ", e );
}
}

You should test this,
but if try throws IO Exception, then your reader wont close.
Maybe have
catch(IOException ex){
reader.close()

An exception can happen anywhere in your code, including finally block, so you have to catch it as anywhere else in your code. Check the following post to get some ideas about the ways you can handle such situation:
throws Exception in finally blocks

Does close()ing InputStream release resoures even if it throws?

Just a simple question. Given this code:
try {
// operation on inputstream "is"
} finally {
try {
is.close();
} catch (IOException ioe) {
//if ioe is thrown, will the handle opened by 'is' be closed?
}
}
If the close() throws, is the file handle still around (and leaked), or will it have been closed?

Not reliably so. If is.close() throws, is might not be marked closed. In any case, there is nothing you can do about it. You don't know the internals of is. The Java 7 equivalent simply hides the problem.
try (InputStream is = Files.newInputStream(...)) {
// Stuff with is.
} catch (IOException is) {
... // Handles exceptions from the try block.
} // No finally. Handled by try-with-reources
If the auto-close throws, the exception is a suppressed exception, and you'll never know if or when the file handle is reclaimed.

Try-with-resources: Must I throw or catch the close() method's exceptions? [duplicate]

This question already has answers here:
Close resource quietly using try-with-resources
(4 answers)
Closed 9 years ago.
Please correct me if this is wrong: In Java 7's try-with-resources statement, any exceptions thrown by the resource's close() method must be either declared as thrown by my method or I must wrap the whole try in another try which catches any exceptions thrown by close().
If so, I have to wonder if I will make much use of it. I certainly don't want to throw the exceptions thrown by close(), the caller won't know what to do with that. And a try wrapping another try just to handle close() would not look very elegant, to me at least.
EDIT: I think I accidentally asked two questions, one of which was a duplicate.
Question 1. Do I have to declare that my method throws the exception from the close() method or wrap the try-with-resources in another try? (Not answered in proposed duplicate.)
Question 2. Is there a way to close the resource silently? (Clearly a duplicate, so I am taking that sentence out of the question. Hopefully this makes the question satisfactorily unique.)

Quote from Java Language Specification ($14.20.3.2):
14.20.3.2 Extended try-with-resources
A try-with-resources statement with at least one catch clause and/or a finally
clause is called an extended try-with-resources statement.
The meaning of an extended try-with-resources statement:
try ResourceSpecification
Block
Catchesopt
Finallyopt
is given by the following translation to a basic try-with-resources statement
(§14.20.3.1) nested inside a try-catch or try-finally or try-catch-finally
statement:
try {
try ResourceSpecification
Block
}
Catchesopt
Finallyopt
The effect of the translation is to put the ResourceSpecification "inside" the try
statement. This allows a catch clause of an extended try-with-resources statement
to catch an exception due to the automatic initialization or closing of any resource.
So, basically, wrapper is already implemented

From the Java tutorial
A try-with-resources statement can have catch and finally blocks just like an ordinary try statement. In a try-with-resources statement, any catch or finally block is run after the resources declared have been closed.
(emphasis mine)
So you can simply do
try (BufferedReader br =
new BufferedReader(new FileReader(path))) {
return br.readLine();
}
catch (IOException e) {
// handle the exception that has been thrown by readLine() OR by close().
}

You do not need to wrap the try-with-resources in another try-catch block, you simply add a catch block:
class Foo implements AutoCloseable {
public void close() throws Exception {
throw new Exception();
}
}
public class Try {
public static void main(final String[] args) {
try(Foo f = new Foo()) {
System.out.println("No op!");
} catch(Exception e) {
e.printStackTrace();
}
}
}

You should be able to simply add the appropriate catch (Exception e) { } clause. If you need to do special handling for a specific one, or you can simply catch Exception, if you need it much broader.
try (Statement stmt = con.createStatement()) {
ResultSet rs = stmt.executeQuery(query);
while (rs.next()) {
String coffeeName = rs.getString("COF_NAME");
int supplierID = rs.getInt("SUP_ID");
float price = rs.getFloat("PRICE");
System.out.println(coffeeName + ", " + supplierID + ", " +
price + ", " + sales + ", " + total);
}
} catch (Exception e) {
System.out.println("Exception while trying to through the queries. ", e);
}
Since it's Java 7, you can actually put multiple exceptions per catch clause, or you can simply catch the outermost exception you want.