Java/Exceptions

Basics

Caught vs uncaught exceptions

The main difference in exceptions is caught versus uncaught exceptions.

http://docs.oracle.com/javase/8/docs/api/java/lang/IllegalArgumentException.html

https://stackoverflow.com/questions/22952140/about-throwing-illegalargumentexception

When an unhandled exception occurs, the program terminates up the call stack -

Illustrating the stack

The Python debugger Pdb shows a better way of "inspecting"/instrumenting the stack easily, and is much more natural to do in an interpreted language. But many of the same concepts hold true in debugging a compiled language. Although things... get weird fast.

The optimal way to run and inspect a program is to run a process, stop it with a debugger insertion call, attach gdb or some other debugger, and continue the process under the control of the debugger, which allows you to explore the process in real time. Alternatively, you can "manage" the execution of the program from some other kind of automated hypervisor, not just a debugger, to make instrumentation of programs much more flexible.

Handling Exceptions

Common Java Exceptions

First, if you want to compile your own list of Java exceptions, each package in the Java standard API will list a package summary on its package summary page. This has an "Exceptions summary" at the bottom that gives a brief summary of all the exceptions defined in a Java package.

For java.io.* the page is here: http://docs.oracle.com/javase/7/docs/api/java/io/package-summary.html

That being said, here are the most common:

Method parameters:

• IllegalArgumentException

Arrays:

• ArrayIndexOutOfBoundsException
• NullPointerException

Collections:

• NullPointerException
• ClassCastException (if not using diamond notation <>)

Type casting:

• ClassCastException

File IO (java.io package):

• IOException
• FileNotFoundException
• EOFException
• ParseException

Everybody:

• NullPointerException

Serialization:

• java.io.ObjectStreamException

Threads:

• InterruptedException
• SecurityException
• IllegalThreadStateException

Unchecked Exceptions

• IllegalArgumentException (UNCHECKED)

Custom Exceptions

/** Empty exception (for stacks) */
class Empty extends Exception {
	// Note, subclass does not inherit any constructor.
	// We can define our constructor and call the super constructor,
	// or we can define no constructor, and always use the default constructor.
	public Empty(String msg) { 
		super(msg);
	}
}

Good Advice

How to design good APIs and why it matters: https://www.youtube.com/watch?v=aAb7hSCtvGw

Implementation should not impact API

Exceptions are examples of where implementation details can leak into the API

• If you have a phone number application, and it throws a SQLException, and now another client wants to implement that code on top of their own proprietary data store and not a SQL store, how do you deal with that?
• Solution? Don't mix implementation details with program details.
• Implements Serializable - entire implementation has just leaked out - serial form now makes ALL of your data, incl private fields, part of public serialized form.
• Solution? Don't say "implements Serializable". Be more careful.

Refs

http://www.javamex.com/tutorials/exceptions/exceptions_unchecked.shtml

Flags

See also:

• Template:DataStructuresFlag
• Template:AlgorithmsFlag