Java unchecked/checked exception clarification

Question

I've been reading about unchecked versus checked questions, none of the online resources have been truly clear about the difference and when to use both.

From what I understand, both of them get thrown at runtime, both of them represent program states that are outside the expected bounds of the logic, but checked exceptions must be explicitly caught while unchecked ones do not.

My question is, suppose for argument's sake I have a method that divides two numbers

double divide(double numerator, double denominator)
{    return numerator / denominator;    }

and a method that requires divison somewhere

void foo()
{    double a = divide(b, c);    }

Who is responsible for checking the case of the denominator being zero, and should an exception be checked or unchecked (ignoring Java's built in divison checks)?

So, would the divide method be declared as is or as

double divide(double numerator, double denominator) throws DivideByZeroException
{
    if(denominator == 0) throw DivideByZeroException
    else ...
}

void foo()
{
    try{
        double a = divide(b, c);
    }
    catch(DivideByZeroException e)
    {}
}

or without a checked exception, as is:

double divide(double numerator, double denominator)
{
    if(denominator == 0) throw DivideByZeroException
    else ...
}

void foo()
{
    if(c != 0)
       double a = divide(b, c);
}

and allow foo to make the divide by zero check?

This problem originally arose in a mathematical program I wrote in which users entered numbers and logic classes performed calculations. I was never sure whether the GUI should check immediately for improper values, or whether the internal logic should catch them during calculation and throw exceptions.

Answer 1

Interesting topic indeed!

After reading and trying lots of way to deal with errors in general and exceptions specifically I learned to differ between programmer errors and a expected errors.

Programmer errors should never be caught, but rather crash (!) early and hard. A programmer error is due to a logical fault, and the root cause should be fixed.

Expected errors should always be caught. Also when a expected error is caught a message must be displayed for the user. This has an important implication - If a expected error should not display an error, it's better to check whether the method will throw instead of letting it throw.

So applied to your example I would think "How should this look to the user?"

1. If a error-message should be displayed (in the browser output, console, messagebox) I would throw an exception and catch it as close to the UI as possible and output the error-message.
2. If no error message should be displayed I would check the input and not throw.

On a sidenote: I never throw DivideByZeroException nor NullPointerException - I let the JVM throw those for me. In this case you could brew your own exception-class or use a suitable built-in checked exception.