• Post Reply Bookmark Topic Watch Topic
  • New Topic

Throwing exception from catch and finally block  RSS feed

 
Rajat Jindal
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

I came across a code where the exceptions can be thrown from catch and finally block too. I never gave a thought on what scenarios that can be required. Can anyone provide some practical examples when/where it can be required to throw the exception from catch and finally blocks.
 
Swaraj Pal
Greenhorn
Posts: 20
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Rajat,
It could be used in many situations , just one of them may be when we need to throw our own custom Exceptions as Java code by default does not throw the exceptions made by the programmer
Its just one case,

e.g.



and in method


 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you should NEVER throw an exception from a finally block, nor exit it in any other abrupt way (such as using return statements). When you call methods from a finally block that throw checked exceptions, catch them, log them and then go on with normal program execution.

For instance, before try-with-resources, this is how you should use streams:
Thankfully, now we can just do this:
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We discussed that sort of thing recently: read this thread. If the finally completes abruptly because it returns something or throws an Exception, then everything else completes abruptly because of the same return or the same Exception.
So returning form a finally overwrites the return values from everything else, and an Exception from a finally overwrites the Exceptions from everything else too. That is why Stephan says never to throw Exceptions nor to return something from a finally.
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There may be good reasons for re‑throwing an Exception, or wrapping it in another Exception.You should find lots about that in the Java Tutorials. You should not be wrapping unchecked Exceptions in checked Exceptions as in the earlier example. You should allow unchecked Exceptions to propagate, and later work out how to prevent them happening. Any subclasses of java.lang.Exception should be called SomethingException.

Now people will tell you that NumberFormatException (NFE) is unavoidable, but that isn't actually true.
If you are reading a file you need to ensure that the format of the file matches the order of tokens used in the program. You can use a Scanner to check the tokens before reading them, and you can even wind back the Scanner, but I have never tried that, and don't know how it works. Not only can a Scanner convert a String or similar input to numbers, but it can also warn you before you read it wrongly. Try this little class and run it from the command line/terminal as follows
java NumberIdentifier 12345 123.45 1234567890.1234567890 12345678901234567890123456789012345678901234567890 -12345 -123.45 -1234567890.1234567890 -12345678901234567890123456789012345678901234567890
Now just as you can use a loop to prevent an InputMismatchException with Scanner, you can use those same methods to prevent NFEs.
 
Rajat Jindal
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hats off to all of you. I got the answer. thanks
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!