Thread: Why do I sometimes get "Unhandled Exception" errors in Eclipse?

Exception handling seems pretty straightforward. Surround your code in a try block, surround the actions you want to take in the event of an error in a catch block.

What I don't get is why sometimes exception handling is mandatory.

If you had code like this one, which does a SQL select query against a database:

protected static ResultSet handleSearchQueries(String searchQuery, int maxRows) 
{
	//Create a new statement and result set.
	Statement newStatement = dbConnection.createStatement();
 
	//Set max rows to be returned.
	newStatement.setMaxRows(maxRows);
 
	//Create and return result set.
	return newStatement.executeQuery(searchQuery);
}

And you run it just like that, Eclipse will snarl at you and say "Unhandled Exception Type SQLException. But if you do something like this:

private void calculateSum()
{
	int num1, num2, result;
 
	Scanner input = new Scanner(System.in);
	System.out.println("Enter the first number: ";
	num1 = input.nextInt();
	System.out.println("Enter the second number: ";
	num2 = input.nextInt();
	result = num1 / num2;
	System.out.println("The quotient is: " +result);
 
}

So if, when prompted for the first number, you wrote "alan", you'd get an InputMismatchException. Because "alan" is not a number. If you were to enter "5" and "0" as your numbers you would get an ArithmeticException, because you tried to divide by zero. And of course you could handle these with try-catch blocks and you should, but what I don't understand is why you aren't forced to handle these, whereas with the SQLException, you are.

Again, I'm not saying that you shouldn't do exception handling... I'm curious as to why it's sometimes required and sometimes optional.

Originally Posted by copeg

It's the difference between checked and unchecked Exceptions. Some info here:
Unchecked Exceptions — The Controversy (The Java™ Tutorials > Essential Classes > Exceptions)
How I'd explain it: in general though not always: unchecked exceptions are thrown by just about everything, and in many contexts are the error of the programmer. Again in general but not always, checked exceptions fall more in the realm of something unexpected caused (directly or indirectly) by a user, and should be dealt with to warn the user

Thanks for the reply and the link. So to clarify... unchecked exceptions are the ones you DON'T have to declare and include situations like:

NullPointerException: User is asked to pick a card, any card, by entering a number from 1-52, because (though this isn't explained to the user) the deck of cards is represented by an array (named deck[]) of 52 elements numbered 0-51. Program fetches deck[userChoice - 1]... but if user is a mischevious bastard and enters the number 70, you get the unchecked NullPointerException and the program crashes if there's not a try-catch block to deal with it.

InputMismatchException: User is asked to enter a number from 1-52 as before, but instead the user is a 7 year old child who writes "fart", which is most definitely not a number?

ArithmeticException: User enters the number 0 as the denominator in a division operation.... though if I recall correctly you usually wanna use doubles for division, and when the numbers are doubles and you divide by 0 you don't get an exception... the program just tells you that the result is "Infinity".

And checked exceptions are the ones that the user couldn't possibly force the program to throw no matter how hard he tried? Because they're entirely caused by events running within the program? Such as:

SQLException: My previous post which queries a database... except that the program can't run the function if there's no connection to the database for some reason. I think it also throws SQLExceptions if there's a syntax error in the SQL query string passed through executeQuery? I forget.

(I had another example but didn't feel like typing it out.)

I don't understand this last part from the link. What do they mean by "if a client can reasonably be expected to recover from an exception"?

If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.