Please throw that book out the window, preferably onto the writer's head.

There are many possible reasons why, in specific cases, one may be better  
than the other.  Take the following:

String getInput()
{
   // get input from the user and return it
}

void showOutput( String output )
{
   // show output to the user
}

void doSomething()
{
   String theInput = getInput();
   // process the input
}

A reasonable approach would be to have getInput just get the input,  
without checking its validity.  Then, doSomething could use the if/else  
case: it checks the input, and if it is invalid notifies the user.
Alternatively, getInput could do some error checking.  Now, if the user  
gives invalid input, what should getInput do?  It might tell the user that  
the input is incorrect and ask new input.  Fine, but what if getInput  
doesn't know how to show output since that is showOutput's task?  (note:  
getInput and showOutput could be methods of different classes) getInput  
knows how to get input, but it has no idea where output should go, what  
format it should have, ...  In that case it is perfectly reasonable to  
have getInput throw a RuntimeException, and have doSomething catch that  
exception and handle it as required.
This is a very simple and somewhat contrived example (input and output are  
typically linked, if only to give the user some indication that input is  
expected - plus, incorrect user input is hardly exceptional so it may not  
be a perfect candidate for Exception usage); there are however countless  
reasons why RuntimeExceptions can be useful.

In the book's defence, it was probably talking about NullPointerException,  
ClassCastException, IllegalArgumentException, etc. which can - in many  
cases - indeed be avoided.

Ben

Usually the front end is considered responsible for making sure only
proper data enters the system.  That way you can prompt the user with a
much more meaningful error message.  It's double checking in a way - but
the class should make sure instance state stays consistent, so usually
setter methods throw if presented illegal data.  The UI check should be
there to additionally make sure the user gets informed what he did wrong
("you did not enter a number in field 'ZIP code'" which is better than
an error you might be seeing from the application like "not numeric").

Kind regards

    robert

Well, yes and no.

Generally RuntimeExceptions should be used in preference to checked
exceptions where a fault in programming is detectable. Checked
exceptions should be used (and hence caught) when dealing with faults
that occur outside of the system (for some suitable definition of system).

A common example of catching a particular RuntimeException is when using
Integer.parseInt. Shouldn't that NumberFormatException be a checked
exception. Well, the method was intended to be used to pass strings from
known good sources. It clearly isn't designed for user input because
there is no internationalisation.

For user input, we need to go to the java.text package.
Format.parseObject is declared to throw ParseException which is checked.
Note that the opposite Format.format throws an unchecked IllegalArgument
exception if the object is unformattable. That is because the object
should come from an internal source and therefore known to be correct.
If it is not correct, then it is a programming error, not a user typo.

Tom Hawtin