Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Unhandled Checked Exception dropped when finally throws an unchecked type - but not via method call

 
Daniel Clinton
Ranch Hand
Posts: 46
5
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm aware that ignoring caught exceptions and throwing from finally
aren't the best ways to program well
but I'm confused by a detail of the compiler's logic.
Here's where my understanding has got to...
The following won't compile due to an unhandled checked type

An unchecked throw from finally however will cause the code to compile while the Checked Exception gets dropped

So, finally runs before the propagation of the Checked exception and the later Exception is given control.
No problem.
But when the RuntimeException is thrown by a method, compilation fails again

If the compiler analyses the flow with regard to finally's behaviour
why does it stop at assessing the call to throwUnchecked()?
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pretend for a moment that all of those were instance methods. throwUnchecked() happens to throw an exception now. But it could be overridden in a subclass and the overridden method might not. This means the compiler can't rely on what happens to be in a public method at the moment. Make sense?

This logic doesn't apply to private methods or static methods. But it would be confusing if Java only looked inside of some methods.
 
Daniel Clinton
Ranch Hand
Posts: 46
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that makes good sense.
Thank you Jeanne
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a great question. Also your analysis to the point you are a little bit is top-notch with accompanying code snippets. Have a cow!

Bottom line: when the compiler is not 100% sure about what will be happening, the compiler will complain by giving you a shiny compiler error

Here is another example with a local variable which is very similar to your example. As you (should) know a local variable must be initialized before you access/use it.

Consider this code snippet:

Although the code has an if-statement, the compiler knows 100% sure that the initialization of variable i will always be executed, so this code compiles successfully.

But if we put the true inside a method, we get a complete other story:


Same rule applies to initialization using an if-statement.

Although there is no way the compiler can know all values of parameter a, used to invoke method1. But the compiler knows b will always get a value: either through the if-block or the else-block. So no complaints and code will compile successfully.

If you add an extra condition to the above if-statement, this guarantee is gone and the code fails compilation:


And what do you think will happen if the 2nd condition (a > 10) is changed to a >= 10 and thus all possible situations (less, equal or greater than 10) are covered?
 
Daniel Clinton
Ranch Hand
Posts: 46
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My instinctive response would be:

For the single if-else
the compiler is assured of one of two eventualities
both of these it assesses as assigning a valid value to b before return
hence, no compilation error

For the if-else if
The certainty of only two possibilities is lost

Even though the condition (a >= 10) would have covered remaining possibilities
The compiler is not evaluating the possible values of a parameter

It merely sees no way b will be returned unassigned in the first case
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Daniel Clinton wrote:For the single if-else
the compiler is assured of one of two eventualities
both of these it assesses as assigning a valid value to b before return
hence, no compilation error

True! This code compiles without error, because variable b is guaranteed to be assigned a value.



Daniel Clinton wrote:For the if-else if
The certainty of only two possibilities is lost

Even though the condition (a >= 10) would have covered remaining possibilities
The compiler is not evaluating the possible values of a parameter

It merely sees no way b will be returned unassigned in the first case

The compiler indeed does not evaluate/check the conditions itself, so it doesn't know that a<10 and a>=10 actually covers all possibilities. It just counts the number of branches and decides on the count if variable b is guaranteed to have a variable assigned. In this example there are just 2 branches (if and else-if) and there should be 3 (if, else-if and else). That's why this code will fail to compile.

So if an else-branch is added the code compiles successfully.


Hope it helps!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic