Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Nested try catch statements  RSS feed

 
Shridhar Raghavan
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



// OUTPUT
java.io.FileNotFoundException: D:\1.txt (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at main.basics.Exceptions.main(Exceptions.java:14)
YO




On running OUTPUT

java.io.FileNotFoundException: D:\1.txt (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at main.basics.Exceptions.main(Exceptions.java:15)
YO


On debugging output


My output for the first program randomly prints "YO" at the beginning and sometimes at the end of the stack trace. How do nested try catch blocks work?



 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shridhar Raghavan wrote:My output for the first program randomly prints "YO" at the beginning and sometimes at the end of the stack trace. How do nested try catch blocks work?

What you're seeing isn't really anything to do with the nested blocks. It's to do with the difference between standard out and standard error, which are actually two separate streams. printStackTrace() writes to System.err (standard error). Under normal circumstances they both write to the same place (although they can be redirected separately), but because they're independent there are no guarantees about the order they write in.

Try writing "YO" to System.err, and you should see the order becomes predictable.
 
Shridhar Raghavan
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. So how are nested try catches evaluated. Was wondering if you the inner catch blocks catches an "Exception" (not a exception), then the outer catch blocks should be unreachable right?
 
Shridhar Raghavan
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Furthermore, how does the control flow between nested try catches and finally. And last, what are the driving motives for using nested try catch blocks.
 
Campbell Ritchie
Marshal
Posts: 55717
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It should be obvious from reading the code how the flow of control goes. The outer catch, as you have already seen, is not called.

By the way: If you change the outer catch to catch (IOException ex), you get a "never thrown" compiler error. That doesn't seem to happen for plain simple Exception.

You should use a try-finally nested inside a try-catch for reading or writing with Readers. The only use of nested try-catch I can think of offhand, however, is to ask questions on CodeRanch about Maybe somebody else can think of a more sensible use.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:If you change the outer catch to catch (IOException ex), you get a "never thrown" compiler error. That doesn't seem to happen for plain simple Exception.

That's because the compiler can't tell whether it's possible that a RuntimeException may be thrown from the inner catch block, which would be caught by the outer catch. The compiler does know that an IOException will never be thrown from the inner catch.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!