• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Difference between the way of throwing exception.

 
kevin saber
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please look at the two codes following :
(a nearly similar question from CertPal)
CertPal SJCP6 wrote:
Code 1:

---------------------------------------------------------------------------------------------------------------------------------------------------
Code 2:




Code 1 will compile, but Code 2 does‘t .
Aren't they really the same ? why the result is different?
 
Rufat Piriyev
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
this because line 13 in second code isn't reachable statement . The reason line 12
 
kevin saber
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rufat Piriyev wrote:

this because line 13 in second code isn't reachable statement . The reason line 12


But the expression "System.out.println("go on");" in line 14 of Code 1 is unreachable, neither. Isn't it?
 
Prithvi Sehgal
Ranch Hand
Posts: 774
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

It is because any exception be it a checked exception or unchecked exception, it must be the last statement of the block.
When you have thrown RuntimeException() from the second block and after that you give a printout statement, think logically,
after you throw an exception, any other code after that can never be reached, because control can never come back once an
exception is thrown. So it makes the statement of printout unreachable and hence the compiler error in code snippet 2.

Hope this helps,
 
jas preet
Ranch Hand
Posts: 78
Eclipse IDE Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
when i compiled and run this code ..for the first i got start ...
but for the second code i got error message like this

C:\>javac Test9.java
Test9.java:14: unreachable statement
System.out.println("go on");
^
1 error


Thanks for clarifications
 
Prithvi Sehgal
Ranch Hand
Posts: 774
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please Kevin,

Quote your sources from where you have copied the code. This is a policy of javaranch that once some
snippet is posted, you must quote the source as well.

Well, no this line which is



is a reachable statement. It is the last line which is this one


is unreachable. I already explained the reason above, that once you throw an exception, control cannot return back to the same
block and after that no block of code is allowed.

Thanks,
 
kevin saber
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. I think i see it
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android C++ Java Linux PHP Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

kevin saber wrote:
But the expression "System.out.println("go on");" in line 14 of Code 1 is unreachable, neither. Isn't it?


Hi Kevin,

Your point is valid. From a human point of view, both programs behave the same way. A dedicated static code analyzer would have flagged the error in both.
But the normal java compiler is not such an advanced code analyzer, because code analysis is not its purpose.
It does it only to a reasonable extent and not more.
In the 2nd example, the throw is part of the same code block, so it's able to "understand" that line 14 will never reach.
But to extend this analysis to any method call in that block can become complicated very quickly for the compiler.
In this example, me() is part of the same file so it's possible to check it. But it might just well as have been part of another jar (as an inherited method), or it might be a method whose body would actually result in 100s of method calls. The compiler never knows. There are too many possibilities and analysis to such an extent will not only take too much time and resources, but also complicate the compiler design itself.
So compilers are designed to make such analysis only to a reasonable depth, to achieve simplicity. Hence, no error in example 1 (And thank heavens for that, else us programmers would be out of work! ).

Cheers
Karthik
 
kevin saber
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Karthik Shiraly wrote:
kevin saber wrote:
But the expression "System.out.println("go on");" in line 14 of Code 1 is unreachable, neither. Isn't it?


Hi Kevin,

Your point is valid. From a human point of view, both programs behave the same way. A dedicated static code analyzer would have flagged the error in both.
But the normal java compiler is not such an advanced code analyzer, because code analysis is not its purpose.
It does it only to a reasonable extent and not more.
In the 2nd example, the throw is part of the same code block, so it's able to "understand" that line 14 will never reach.
But to extend this analysis to any method call in that block can become complicated very quickly for the compiler.
In this example, me() is part of the same file so it's possible to check it. But it might just well as have been part of another jar (as an inherited method), or it might be a method whose body would actually result in 100s of method calls. The compiler never knows. There are too many possibilities and analysis to such an extent will not only take too much time and resources, but also complicate the compiler design itself.
So compilers are designed to make such analysis only to a reasonable depth, to achieve simplicity. Hence, no error in example 1 (And thank heavens for that, else us programmers would be out of work! ).

Cheers
Karthik


It sounds really complicated. I hope this kind of question never comes out in SCJP test. T_T!
And thank you.
 
Larry Chung
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Karthik, for explaining the subtle truth about compiler design. Without remembering that, it's possible to make mistakes in evaluating code with nested method calls.
 
Prithvi Sehgal
Ranch Hand
Posts: 774
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True Larry. Thanks for sharing such a stuff Karthik.

Best Regards,
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic