exception handling : Java Glossary

Exceptions let you handle unusual error conditions without cluttering your code with nested ifs after every method call. You can use a single piece of code at a higher level to deal with all the exceptions triggered at a lower level. You can handle some of the exceptions at lower levels and others at a higher level and others you don’t handle at all, just let them terminate your program. There are two kinds of Exceptions, checked and unchecked. You don’t need to declare unchecked Exceptions, those that derive from java.lang.Error and java.lang.RuntimeException, in your throws clauses. Checked Exceptions usually derive from java.lang.Exception.

For unchecked Exceptions ( i.e. Errors and RuntimeExceptions such as IllegalArgumentException) the throws clause is optional. I find them useful documentation since they show up in the Javadoc.

Sample Code

String trickyMethod() throws IOException
{
   int result = readAnotherChar();
   if ( result < 0 ) throw new IOException( "bad data" );
   return result;
}

Types of Exception

If you catch RuntimeException you will catch all manner of run time Exceptions (type R).
If you catch Error you will catch all manner of errors (type E).
If you catch Exception you will catch all manner of checked Exceptions and run time Exceptions (type R+C).
If you catch Throwable, you will catch everything, (Type R+E+C );

If the Exception is checked, you must either fob it off on the caller, with the throws clause or catch it yourself. Unchecked Exceptions are ones like running out of RAM (Random Access Memory) that, in general you can’t do much about, or that are not associated with specific problematic code, or that are very common such as IllegalArgumentException or NullPointerException. You don’t have to catch unchecked Exceptions or explicitly fob them off on the caller with throws. The classification of an Exception is not an exact science. It is a little bit like the arbitrary assignment of gender in French or German to objects. You just have to look it up. There is a major clue, Error Exceptions end in the string Error while checked Exceptions and RuntimeExceptions end in the string Exception.

Table of Specific Exceptions

Missing BadDataFormatException

Roll Your Own Exception

Status Code or Exception?

• There is nothing that says the caller has check a status code. Programmers are lazy and don’t bother to check return codes. No error or warning is generated.
• If the caller of the caller is the proper place to handle the exception it takes futzing to propagate the information up the chain.
• Exceptions should be exceptional. They are for errors, things that are not supposed happen. EOFException is a special case. It will happen at most once per file. If there are 50/50 odds of either status, you should use a status code. There is an extra overhead to catching an exception. Don’t use Exceptions to return common place data or status. A rule of thumb might be if a method returns an error more often than 1 in 10, use a status code instead of an Exception to report the problem.

Books

Book referral for Java in a Nutshell

	recommend book⇒Java in a Nutshell
	by	Benjamin J Evans, David Flanagan	978-1-4493-7082-4	paperback
	publisher	O’Reilly	978-1-4493-7131-9	eBook
	published	2014-11-06	B00OL0853O	kindle
Online bookstores carrying Java in a Nutshell abe books anz abe books.ca abe books.de amazon.ca amazon.de Chapters Indigo amazon.es Chapters Indigo eBooks iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Nook at Barnes & Noble amazon.it Kobo junglee.com Google play abe books.co.uk O’Reilly Safari amazon.co.uk Powells other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Learning More