• Post Reply Bookmark Topic Watch Topic
  • New Topic

Basis for deciding checked exception and unchecked exception  RSS feed

 
raja singh kumar
Ranch Hand
Posts: 189
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On what basis was it decided that some exception should be a compile time exception or run time exception or was it decided randomly?

1. Can the compiler not detect at compile time if there is an arithmetic(divide by zero) exception?
2. Can the compiler not detect whether a method has been called on null which could cause NullPointerException?


 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just a very simple case but how is the compiler supposed to detect either of those conditions with the following code? Remember, the compiler can only do static analysis because it never actually executes code.

In case you have any doubts, the answer is, it can't.
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Similar question about nulls. Is the following reference going to be null or not; will line 3 cause an Exception to be thrown?
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There was nothing random about the design of the language. It was decided at the beginning what can and what cannot be determined at compile time. The addition of generics in 2004 increased the number of compile‑time errors. Only in a few cases was it possible to go through the code and check its likely execution at compile time. One such instance is local variables being “effectively final”. But in most cases it is if not impossible, at least very time‑consuming and difficult, to verify the value of a particular variable and whether an NPE will be thrown, or division by zero occur. Those errors are therefore defined as runtime errors which are signalled by Exceptions.

Of course, the errors which make it past the compiler and don't throw Exceptions are the really nasty ones. They are the logic errors and they cause things like wrong results, very slow performance, financial losses running into millions, or even fatal accidents.
 
raja singh kumar
Ranch Hand
Posts: 189
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It was decided at the beginning what can and what cannot be determined at compile time.

It is not possible to detect at compile time if a file will be found at a particular location or not. On what basis was FileNotFoundException made as a checked exception?
 
Paul Clapham
Sheriff
Posts: 22835
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's a checked exception because it's an error which is caused by the environment. Unchecked exceptions are pretty much all exceptions which are caused by programmer error. For example NullPointerException is caused when the programmer writes code which attempts to call a method or access a field of a null reference; this is an error which can be avoided by proper programming.
 
Maneesh Godbole
Bartender
Posts: 11445
18
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All excellent explanations above. +1

When I learnt about exceptions, I formulated a simple rule in my mind to help understand it better.

All things which can go wrong but are not under the developers control : Checked exception
All things which can go wrong but can be avoided by the developer : Unchecked exception

 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!