We Keep Coding

Java 'finally' clause in a nested 'try' block

Will the following finally clause be executed, if an exception is thrown by the PrintWriter?
try{
PrintWriter out = new PrintWriter(filename);
try {
//output
} finally {
out.close();
}
} catch {
//handle exception
}
If the PrintWriter throws an exception, then the nested try block will never get executed, but why the nested finally clause will still be executed, even it's nested and skipped?
Updates:
I ran some tests, if an exception is thrown before the nested try clause, that nested finally will not be executed.
If the exception is thrown inside the nested try clause, then the inner finally and the outter catch will be executed.

No because the inner try block will not be reached when an exception occurs before and therefore the finally block is not reached either.

Finally block is always executed whether exception is handled or not. Even though their is an error and it reaches to catch block, it will go to finally block to execute the piece of code.
finally block is a block that is used to execute important code such
as closing connection, stream etc.
So, Inside try{} block you placed try and finally, but you asked about the catch of outside try ,thus its not going inside the first try block.That finally wont work.
P.S. : If you put finally something like this:
try{
try{...}
finally{...}
}catch(Exception e){...}
finally{... }
//in case of exception also , the outside finally is going to work.
P.S.: Though you got your answer , but the concept is for reference of other naive programmers

An uglier variant (sometimes generated by the IDE) one sees also:
// *** UGLY
PrintWriter out = null;
try {
out = new PrintWriter(filename);
//output
} catch (IOException e) {
//handle exception
} finally {
if (out != null) {
try {
out.close();
} catch (IOException e2) {
// IGNORE
}
}
}
That explains the code a bit: as close may throw an IOException too, the code becomes cumbersome. Your code still needs nested exceptions.
With try-with-resources this can & should be written as:
try (PrintWriter out = new PrintWriter(filename)) {
//output
} catch (IOException e) {
//handle exception
} // Automatically closes.
And no longer nested exceptions.
The biggest advantage is that you need not catch any exception, and just add a throws IOException in the method signature.

Java: Poor error handling, Throw inside Finally

I have the following code which I am running through fortify. Why it gets marked for poor error handling, throw inside finally?
private String getResourceContent(String fileName) throws IOException {
try (InputStream resource = ErrorResource.classLoader.getResourceAsStream(fileName)) {
return new String(resource.readAllBytes(), StandardCharsets.UTF_8);
} catch (NullPointerException n) {
throw new ErrorDescriptorException(
String.format("Error loading Error description data from Resource file [%s].", fileName), n);
}
}

Explanation
This is explained very well in the official documentation (see Poor Error Handling: Throw Inside Finally). Let me quickly quote the important sections:
Using a throw statement inside a finally block breaks the logical progression through the try-catch-finally.
In Java, finally blocks are always executed after their corresponding try-catch blocks and are often used to free allocated resources, such as file handles or database cursors. Throwing an exception in a finally block can bypass critical cleanup code since normal program execution will be disrupted.
So you can easily bypass cleanup code by doing that, which leads to resource leaks.
Although not directly visible in your code, you actually have a hidden finally block since you are using try-with-resources which automatically closes the resource in a finally block.
Also see Throwing an exception inside finally where this was already discussed.
Example
Here is an example from the official documentation:
public void processTransaction(Connection conn) throws FileNotFoundException {
FileInputStream fis = null;
Statement stmt = null;
try {
stmt = conn.createStatement();
fis = new FileInputStream("badFile.txt");
...
} catch (FileNotFoundException fe) {
log("File not found.");
} catch (SQLException se) {
// handle error
} finally {
if (fis == null) {
// This bypasses cleanup code
throw new FileNotFoundException();
}
if (stmt != null) {
try {
// Not executed if the exception is thrown
stmt.close();
}
catch (SQLException e) {
log(e);
}
}
}
}
The call to stmt.close() is bypassed when the FileNotFoundException is thrown.
Note
Why are you checking for null using a NullPointerException instead of a basic if-else? There is rarely ever a valid reason to catch a NullPointerException. Just do:
try (InputStream resource = ErrorResource.classLoader.getResourceAsStream(fileName)) {
if (resource == null) {
// TODO Throw your exception here
}
return new String(resource.readAllBytes(), StandardCharsets.UTF_8);
}
It might also help to improve the error message by telling the exact reason that the resource could not be found.

Consider the following code, which is loosely based on yours:
String throwing(InputStream inputStream) throws IOException {
try (InputStream resource = inputStream) {
return "good";
} catch (NullPointerException n) {
return "bad";
}
}
You see, no exceptions thrown here. Still, you cannot remove the throws IOException bit – how’s that? Well, InputStream#close() can throw it, and it will be in the implicit finally block that the try-with-resources statement created. I guess there’s not much you can do about it, it looks like a Fortify false positive.

Beyond the misleading message from your tool, there is actually is poor error handling in your code, for multiple of reasons:
catching NPE is really bad practice. Either it is a bug (something that is null and shouldn't), or your code is missing a check if (whatever == null) and the corresponding code to deal with that expected situation
assuming that this NPE has exactly that meaning that you express in your new Exception is well, just guessing
In other words: without further information, it is not clear what exactly your tool complains about. But: one doesn't need a tool to understand: this is poor error handling.
Beyond that, such tools typically give some sort of information about their warnings. Meaning: there might be an "error id" coming with that warning, and you should be able to look up that "error id" in the documentation of your tool for further explanations.

ScriptEngineManager extra cautious exception handling

I wanted to consult about JDK code exception handling,
In ScriptEngineManager from lines 120 there are unused secondary catch for ServiceConfigurationError which can't be thrown as I understand it
try {
while (itr.hasNext()) {
try {
ScriptEngineFactory fact = (ScriptEngineFactory) itr.next();
facList.add(fact);
} catch (ServiceConfigurationError err) {
System.err.println("ScriptEngineManager providers.next(): "
+ err.getMessage());
if (DEBUG) {
err.printStackTrace();
}
// one factory failed, but check other factories...
continue;
}
}
} catch (ServiceConfigurationError err) {
System.err.println("ScriptEngineManager providers.hasNext(): "
+ err.getMessage());
Is there a reason why a second catch will be necessary? it seems it effect only while (itr.hasNext()) which doesn't throw any exception
Or is it just overly cautious to ensure method not throwing exception in any case, as commented
// do not throw any exception here.
Actually java allows you to duplicate such try-catch without any error/warning:
try {
try {
ScriptEngineFactory fact = itr.next();
engineSpis.add(fact);
} catch (ServiceConfigurationError err) {
err.printStackTrace();
}
} catch (ServiceConfigurationError err) {
err.printStackTrace();
}
If I'll concatenate catches in same try I would get compilation error
Unreachable catch block for ServiceConfigurationError. It is already handled by the catch block for ServiceConfigurationError

Minor misconception: the second catch does not only cover the while loop. It would also take care about such exceptions thrown from within the first catch block.
But you are correct: that catch block, as well as the loop "header" should not throw such an exception. It seems rather odd that simply iterating an iterator needs "protection" in such a way.
Thus: maybe this is a leftover when other code existed in that method. Or it is overdoing. Or worst case, the code that we don't see (that creates that iterator) can in fact throwing that kind of error. Which, as said, would be odd and a very bizarre design, to say the least.

Is there a way to throw IOException in a runnable?

I have some code thats not working(which is a common occurrence for me), but because I am not getting an errors it just continues to run with bad data. The problem I think is it keeps telling me to wrap parts of my code in try/catch blocks(my tests are basic, I just output a message in the try area and if it gets outputted I assume all went well. All does not seem well in my code). I understand in production, putting a try/catch statement helps the code to continue to run but its making me troubleshooting difficult because I'm trying to troubleshoot that section of my code.
Is there a way around this so I can actually see when something fails within the try area?
Here's a sample of my code:
try {
ByteArrayInputStream baos_back = new ByteArrayInputStream(message);
ObjectInputStream oos_back = new ObjectInputStream(baos_back);
i = oos_back.readInt();
d = oos_back.readDouble();
list_of_ints = (int[]) oos_back.readObject();
oos_back.reset();
baos_back.reset();
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

Are you trying to get your program to blow up when this error occurs? If so, you should be able to wrap your IOException in a RuntimeException and throw that instead. They're unchecked, so you don't need to declare them and it should kill your program just fine.

If you want your code to throw the appropriate exception, I'd suggest not using try-catch blocks at all. Try-catch is used to handle exceptions as they arise and then keep running the program, but it sounds like you don't want to handle them at all.
If you do want to use try-catch blocks you could always manually throw a RuntimeException at the end of the catch block.
Something like:
throw new IOException();
try {
// Some code...
} catch(Exception e) {
// Error handling code...
throw new RuntimeException(e.getMessage());
}

As I mentioned in my comment, you can catch all exceptions in Java with a blanket catch statement:
try {
// code
} catch (Exception e) {
e.printStackTrace();
}
This will catch every Exception thrown in the try block, and the only things it won't catch are Errors.
In practice, you will want to limit the types of exceptions you catch, and catch more specific exceptions, so you can exception chain as follows:
try {
// code
} catch (IOException ioe) {
// we expected this
ioe.printStackTrace();
} catch (SomeOtherException soe) { // just an example...
soe.printStackTrace();
} catch (Exception e) {
// Did we expect this? Maybe not!
e.printStackTrace();
}
The above also makes it known that you expect some types of exceptions to occur, and then a big blanket catch-all statement that might catch things you didn't expect.
You can also log exceptions to a file or something else, rather than output them to standard out as this code does right now. A basic logging utility is java.util.logging.
I still recommend learning to use a debugger though. Debuggers can do a lot of things like halt program execution whenever an exception is thrown, and allow you to inspect the values of variables and fields at any point in the program's execution. If you use Eclipse or Netbeans or IntelliJ or other IDEs, they have debuggers. If you use the command line, there is the jdb command-line java debugger.

I suggest editing your code generation template to do this
catch ( $ExceptionClass e )
{
// TODO: Autogenerated catch block
e.printStackTrace();
throw new RuntimeExcepton( e );
}
This way you have a TODO reminder, a barf on stdout, and are ensured that your program will blow up if you do not provide correct exception handler.

Java exception handling

How do I use exceptions and exception handling to make my program continue even if an exception occurs while processing certain files in a set of files?
I want my program to work fine for correct files while for those files which cause an exception in program, it should ignore.
Regards,
magggi

for(File f : files){
try {
process(f); // may throw various exceptions
} catch (Exception e) {
logger.error(e.getMessage(), e);
}
}

You have to use the try/catch/finally blocs.
try{
//Sensitive code
} catch(ExceptionType e){
//Handle exceptions of type ExceptionType or its subclasses
} finally {
//Code ALWAYS executed
}
try will allow you to execute sensitive code which could throw an exception.
catch will handle a particular exception (or any subtype of this exception).
finally will help to execute statements even if an exception is thrown and not catched.
In your case
for(File f : getFiles()){
//You might want to open a file and read it
InputStream fis;
//You might want to write into a file
OutputStream fos;
try{
handleFile(f);
fis = new FileInputStream(f);
fos = new FileOutputStream(f);
} catch(IOException e){
//Handle exceptions due to bad IO
} finally {
//In fact you should do a try/catch for each close operation.
//It was just too verbose to be put here.
try{
//If you handle streams, don't forget to close them.
fis.close();
fos.close();
}catch(IOException e){
//Handle the fact that close didn't work well.
}
}
}
Resources :
oracle.com - Lesson: Exceptions
JLS - exceptions

I guess your new to programming as execeptions are a fairly fundermental concept, as problems can happen out of your control and you need to deal with it.
The basic premise is a try catch block.
try
{
//Your code here that causes problems
}
catch(exception ex)
{
//Your code to handle the exception
}
You 'try' your code, and if an exception is raised, you 'catch' it. And do what you need.
There is also an addition to the catch block in that you can add finally{} below it. Basically even if no exception is raised the finally code is still run. You may wonder the point in this, but its often used with streams/file handling etc to close the stream.
Read more on java exceptions here in tutorials written by Sun (now Oracle)- http://download.oracle.com/javase/tutorial/essential/exceptions/
try
{
//Your code here that causes problems
}
catch(exception ex)
{
//Your code to handle the exception
}
finally
{
//Always do this, i.e. try to read a file, catch any errors, always close the file
}
The question you may ask is how do you catch different exceptions, i.e. is it a null reference, is it divide by zero, is it no file found or file not writeable etc. For this you write several different catch blocks under the try, basically one catch for each type of exception, the use of "exception" is basically a catch all statement, and like in stack of if statements if an "exception" is the first catch block it will catch everything, so if you have several catch blocks ensure exception is the last one.
Again, this is a useful but large topic so you need to read up about it.
Since you are doing multiple files, you need to basically do a loop and within the loop is contained the try/catch block.
so even if one file fails, you catch it, but carry on running, the code will then loop around onto the next file unhindered.

just catch the excpetion it may throw and do nothing with it; eat it as people say :)
But at least log it!
Very concise example:
try {
your code...
} catch (Exception e) {
log here
}

Typically, I would have done this.
ArrayList<Entry> allEntries = getAllEntries();
for(Entry eachEntry:allEntries){
try{
//do all your processing for eachEntry
} catch(Exception e{
ignoredEntries.add(eachEntry);
//if concerned, you can store even the specific problem.
} finally{
//In case of resource release
}
}
if(ignoredEntries.size() > 0){
//Handle this scenario, may be display the error to the user
}

FileSystemException may be the specific exception you are looking for.
Although, a better idea for beginners is to catch an exception and print it using
System.out.println(e);
where e is the caught exception.

public class Main
{
public static void main(String args[])
{
int a=10;
try
{
System.out.println(a/0); //Here it is not possible in maths so it goes to catch block
}
catch(ArithmeticException e)
{
System.out.println("Arithmetic Exception");
}
}
}
output:Arithmetic Exception

Exception in java are runtime error which can be handled by the program, the process is called as exception handling. Parent class of exception is Throwable.
Exception : Exception are those runtime error which can be handled by program.
Error : Those runtime error which can’nt handled by the program.
Tools used to handle Exception:
Try
Catch
Finally
Throw
Throws
more