This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Java in General and the fly likes Exceptions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Exceptions" Watch "Exceptions" New topic
Author

Exceptions

Amit Mohan Tiwari
Greenhorn

Joined: Aug 21, 2006
Posts: 10
Would anyone tell me the

the interview related definitions of checked and unchecked exceptions

and the difference between them

Thanks
Srikanth Basa
Ranch Hand

Joined: Jun 06, 2005
Posts: 241
Even if it were an interview or not the definitions still remain the same

Checked exception - The exceptions which can be detected at compile time and which must be either caught or thrown. E.g. SQLException

Unchecked Exception - The exceptions that can be thrown due to issues in programming and these cannot be detected during compile time and hence the java compiler doesn't ask you to either catch or throw these exceptions. These exceptions extend the RuntimeException. NPE and IAE are famous unchecked exceptions.

Say these and the interviewer will not ask you anything else on Exceptions
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

Originally posted by Srikanth Basavaraju:
Say these and the interviewer will not ask you anything else on Exceptions

Really? I do interview people who come to apply for a job sometimes. Apart from the fact that I don't exactly agree with your definition (your answer is wrong), my next question would be: When would you use checked exceptions, and when would you use unchecked exceptions, and why?

It is not so that an unchecked exception "cannot be detected during compile time". Checked / unchecked doesn't have anything to do with whether the compiler can or cannot detect if they could be thrown.

For checked exceptions, the compiler checks if the programs handles them (by either surrounding code that can throw a checked exception with a try-catch block, or by specifying that the method propagates the exception through a throws clause).

For unchecked exceptions, the compiler doesn't check if the program handles them.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
When would you use checked exceptions, and when would you use unchecked exceptions, and why?


And then for 60 seconds take the other side of the controversy.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Everyone is wrong.

A CheckedException is one that originates in a landlocked republic in central Europe.

Oh, nevermind, my mistake. That's a CzechedException.

If I was asking the question, I'd hire you all, because all of those answers sounded pretty darn good.

When do you use Czech vs. Checked vs. Unchecked?


Unchecked are typically runtime exceptions, like ArrayOutOfBounds or NullPointer. The loom over your programs like a lion ready to strike. They're always there, and you can choose to handle them if you anticpate a problem like that, or you can let them go.

Checked exeptions you MUST handle, or your code won't compile. A method that uses another method that throws an exception must handle that exception in a try-catch block, or throw the exception in its own method declaration.

Again, a CzechException is one that originates in central Europe. You can use those whenever you see fit.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I prefer plaid to checked, but haven't found much opportunity to use them.
Srikanth Basa
Ranch Hand

Joined: Jun 06, 2005
Posts: 241

It is not so that an unchecked exception "cannot be detected during compile time". Checked / unchecked doesn't have anything to do with whether the compiler can or cannot detect if they could be thrown.

For checked exceptions, the compiler checks if the programs handles them (by either surrounding code that can throw a checked exception with a try-catch block, or by specifying that the method propagates the exception through a throws clause).

For unchecked exceptions, the compiler doesn't check if the program handles them.

Hmm let me speak from where I bring in the topic of compilation.
Try these two and I hope you understand what I mean by what I said


Srinivas Kalvala
Ranch Hand

Joined: Oct 20, 2005
Posts: 257

Hello,

As I believe the usage of checked and Unchecked depends on the design of a particular architecture. Most of the application will wrap the checked exceptions in unchecked exceptions and will throw them to the main handler.

If it comes to API, then most application will prefer throwing checked exceptions.

There is no hard and fast rule to define the usage of checked & unchecked exceptions.

More inputs are welcome,
Matt Harrah
Ranch Hand

Joined: Aug 05, 2006
Posts: 54
Personally, I'd rather hire the people who are giving the answers. If I were the hiring manager I'd be looking for the people who actually understand the difference between a checked an unchecked exception rather than need to get an answer to repeat at an interview.

And if I were the candidate, I'd be looking for actual understanding and work experience with Exception classes, rather than a canned answer.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37955
    
  22
Posted by Kameron McKenzie
Unchecked are typically runtime exceptions, like ArrayOutOfBounds or NullPointer. The loom over your programs like a lion ready to strike. They're always there, and you can choose to handle them if you anticpate a problem like that, or you can let them go.
Loom over your programs? No they don't. Unchecked exceptions are almost always errors in the coding which need to be found and corrected before the app is let loose on an unsuspecting world.
Look at the common ones: NullPointer, SomethingOrOtherOutOfIndex, IllegalArgument, Arithmetic. All caused by programming errors.
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12760
    
    5
It is not so that an unchecked exception "cannot be detected during compile time". Checked / unchecked doesn't have anything to do with whether the compiler can or cannot detect if they could be thrown.


What? Would you care to explain that. If I was interviewing and somebody said "Checked / unchecked doesn't have anything to do with whether the compiler can or cannot detect if they could be thrown." the interview would probably terminate right there.

Bill
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Matt Harrah:
Personally, I'd rather hire the people who are giving the answers. If I were the hiring manager I'd be looking for the people who actually understand the difference between a checked an unchecked exception rather than need to get an answer to repeat at an interview.

And if I were the candidate, I'd be looking for actual understanding and work experience with Exception classes, rather than a canned answer.


If skill was a primary objective, I'd hire someone who is able to provide a critical analysis of what exceptions really are. Nothing to do with "programming errors" or "recoverable errors" or any of that gumph - I agree - do away with canned reiterations for answers.

If I were the candidate however, I'd provide a canned answer that is generally accepted as truth, then once I received the job offer, I'd demonstrate why my answer was wrong to the interviewer (I am smiling with my boss right behind me )


Tony Morris
Java Q&A (FAQ, Trivia)
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Loom over your programs? No they don't. Unchecked exceptions are almost always errors in the coding which need to be found and corrected before the app is let loose on an unsuspecting world.


You're making the assumption that there are no errors in my coding. I certainly appreciate the benefit of the doubt, but if you saw some of my code, you might not disagree.



-Cameron
Srikanth Basa
Ranch Hand

Joined: Jun 06, 2005
Posts: 241

Unchecked are typically runtime exceptions, like ArrayOutOfBounds or NullPointer. The loom over your programs like a lion ready to strike. They're always there, and you can choose to handle them if you anticpate a problem like that, or you can let them go.


I just wonder why you want to handle Unchecked exceptions

In simple, I don't think catching and handling NullPointerException makes any sense when I know the truth behind the entire story that my code has issues.
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12760
    
    5
In simple, I don't think catching and handling NullPointerException makes any sense when I know the truth behind the entire story that my code has issues.

AND - if you really want to know where those issues start, you WILL catch the exception and get the stack trace.

The other reason for paying attention to unchecked exceptions is exceptions you create and throw for diagnostic purposes. For example, I like to use IllegalArgumentException - created with an informative message of course - when one of my methods gets bad data.

Bill
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Srikanth]: I just wonder why you want to handle Unchecked exceptions

This shouldn't be shocking. Sometimes you're working on a system that is expected to keep on running even if errors occur. If possible, anyway. For example, a web server shouldn't crash just because one of its web applications threw a RuntimeException. You should almost always log such an error, which usually means you need to catch it first, at some level.

Also, some unchecked exceptions are not programming errors. Look at Integer.parseInt(), which throws a NumberFormatException. Typically that's not the programmers fault at all; it's bad input. Which the programmer needs to handle. And one can argue over whether it should have been a checked or unchecked exception, but that's not terribly productive at this point - it is an unchecked exception, and it's perfectly reasonable to catch it in your code to handle the case of bad user input. If that's a common occurrance you may want to try other strategies, but that's a longer discussion. For many simple cases you can just use Integer.parseInt(), and catch the exception where appropriate.


"I'm not back." - Bill Harding, Twister
Srikanth Basa
Ranch Hand

Joined: Jun 06, 2005
Posts: 241

Also, some unchecked exceptions are not programming errors. Look at Integer.parseInt(), which throws a NumberFormatException.

Aha Jim Yingst has a good point here. Now the question here is what was the initial idea of Sun while classifying the unchecked exceptions ?

(As you already showed that the unchecked exceptions need not be programming issues in all the cases)

So do you still mean the original idea of using Runtime exceptions was for programming issues but it was not taken care while designing NumberFormatException ?
[ September 05, 2006: Message edited by: Srikanth Basavaraju ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Don't forget that when Sun designed Checked and Unchecked exceptions, they had less Java experience than you do today. These were also rather new and experimental ideas in language design. So their original intent doesn't worry me much.

Blanket statements like unchecked exceptions are the programmer's fault or you shouldn't catch them are not very useful when you have to build a real system. When my choice is "catch exception" and keep the system up or let unchecked exceptions bring the system down, I'm catching everything.

Just one more example: An out of memory error does not mean the JVM is in any kind of trouble or should be terminated. It means there was not enough memory to allocate one new object right this moment. You might let the user try again later or specify a smaller size.

Of course you don't want to put try-catch around every "new Object()" statement. In server systems we usually have a thread or a call stack that starts with a user request coming in. I might put just one catch-all at the top of this stack, doing my best to make sure I return something in response, even if it's just "Wow, that didn't work!"
[ September 05, 2006: Message edited by: Stan James ]
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by William Brogden:


What? Would you care to explain that. If I was interviewing and somebody said "Checked / unchecked doesn't have anything to do with whether the compiler can or cannot detect if they could be thrown." the interview would probably terminate right there.

Bill


In what way does it have anything to do with whether or not the compiler can detect whether it can or cannot be thrown? The literal difference between the two is that the compiler checks for one and forces programmers to handle it but doesn't check for the other. What usage is extracted from that is another story, but to my knowledge it has nothing to do with the compiler's ability to detect them.

The JLS actually indicates that the compile-time checking is merely there to reduce the number of exceptions that aren't properly handled. It also indicates that errors aren't checked because they're uncommon are too difficult to recover from. Runtime exceptions aren't checked because it would be little more than an irritation to a programmer who might easily be able to see that the exception will never occur.

I suppose a logical conclusion is that it's impossible for a compiler to detect that unchecked exceptions exist, but that's a symptom rather than a cause.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Exceptions
 
Similar Threads
writing from a jar
while loop
executeBatch() not executing
my query is successfully running in database but it is returning empty resultset in my java program
Questions from mock Exam !!!