I am curious to know what is the use of Unchecked Exceptions. These are the exceptions which programmer is not supposed to catch in the code or declare in the method signature and even compiler doesn't check for these exceptions. Then, why these exceptions have been provided in Java??
Jeanne Boyarsky wrote:A lot of the time you can't do anything about an exception. Suppose the database is down. Does every class in your app REALLY need to throw a SQLException? Instead, an unchecked exception lets you propagate it up to the top level and deal with "something unexpected" just the once.
So, what is the best approach to handle the Runtime (CHECKED) exceptions in java at different layers?
Vaibhav G Garg wrote:I am curious to know what is the use of Unchecked Exceptions. These are the exceptions which programmer is not supposed to catch in the code or declare in the method signature...
Actually, you're not required to, which is very different.
Then, why these exceptions have been provided in Java??
The truth is, more people ask: Why were checked Exceptions provided?
My answer is (and I know I'll get flamed by people who love checked Exceptions): I suspect that it's an idea that seemed good on paper at the time, but actually has little practical use. Even I like the idea of checked exceptions; but unfortunately their implementation - especially in a lot of java.io and java.sql classes - falls short of what I suspect was the intent.
However, Campbell's quite right: you should read the tutorials ... although even they might not answer all your "why" questions.
manish ghildiyal wrote:My understanding of unchecked exceptions is that it informs that there is some thing fatally wrong with code which needs to be taken care of. Checked exceptions, on other hand, represent those scenarios where user may have provided some wrong data,like non-existing file, and hence killing a program due to wrong user input doesn't make sense.
Yup, that was certainly the intent; but it's been ruined down the years by lazy implementations that throw "amorphous" things like IOException and SQLException (both of which are checked) willy-nilly.
What am I supposed to do if a database is down, or I get a disk read error when accessing a file?
For starters, I don't even know that that's what happened, since nobody bothered to create a DatabaseIsDownException or DiskReadError (the latter of which arguably shouldn't be checked anyway); and once I've got past the point of establishing a connection to a database, the rest of the API should either:
(b) Throw an Error (eg, if a network connection goes down).
(c) Throw an Exception that indicates a logic flaw (eg, a badly-formed piece of SQL); and IMO that's still a runtime error - because it indicates a bug - and so probably shouldn't be checked either.
One of the things that tells me that many of these APIs are flawed is the recent appearance of the java.nio package, which contains lots of goodies for avoiding IOException. I wonder when java.nsql will appear?