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
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.
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.
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
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.
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.
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
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.
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 )
Cameron Wallace McKenzie
,
author and cow tipper
staff
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.
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
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.
[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.
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 ]
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 ]
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.
Post by:autobot
I wish to win the lottery. I wish for a lovely piece of pie. And I wish for a tiny ad:
a bit of art, as a gift, the permaculture playing cards
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
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.
