How to Throw an Exception

The throw statement in your  methods throw an exception. The throw statement requires a single argument: a throwable object. Throwable objects are instances of any subclass of the Throwable class. Here's an example of a throw statement.

throw someThrowableObject

When an exception is thrown, the thrower provides an object that describes the exception, similar to an error code. Typically applications define a different exception object for each type of error that may occur, and then provide fields in the object that give more details about the error.

The throw is matched by examining the catch statements that follow the try statement in sequential order. That means that exception handlers with more restrictive types should be placed before exception handlers with more general types. If the throw cannot be matched locally then it is dynamically propagated up the call chain.

More About the Finally Clause

A finally clause is usually included to make sure that some clean-up (e.g., closing opened files) is done.  Also, A finally clause always executes whether or not there is an exception. Furthermore, if the finally clause includes a transfer of control statement (return, break, continue, throw) then that statement overrides any transfer of control initiated in the try or in a catch clause. First, let's assume that the finally clause does not include any transfer of control. Here are the situations that can arise:

No exception occurs during execution of the try, and no transfer of control is executed in the try clause.	The finally clause executes, then the statement following the try/catch/finally block.
No exception occurs during execution of the try, but it does execute a transfer of control.	The finally clause executes, then the transfer of control takes place.
An exception does occur during execution of the try, and there is no catch clause for that exception.	The finally clause executes, then the uncaught exception is "passed up" to the next enclosing try block, possibly in a calling function.
An exception does occur during execution of the try, and there is a catch clause for that exception. The catch clause does not execute a transfer of control.	The catch clause executes, then the finally clause, then the statement following the try/catch/finally block.
An exception does occur during execution of the try, there is a catch clause for that exception, and the catch clause does execute a transfer of control.	The catch clause executes, then the finally clause, then the transfer of control takes place.

If the finally block does include a transfer of control, then that takes precedence over any transfer of control executed in the try or in an executed catch clause. So for all of the cases listed above, the finally clause would execute, then its transfer of control would take place. Here's one example:

    try {
        return 0;
    } finally {
        return 2;
    }
    

The result of executing this code is that 2 is returned.

Note that this is rather confusing! The moral is that you probably do not want to include transfer-of-control statements in both the try statements and the finally clause, or in both a catch clause and the finally clause.

Overriding methods that throw exceptions

The throws clause of the overriding method in a subclass may only include those exceptions, or subclasses of those exceptions that can be thrown by the overridden method of superclass. In other words, an overriding method may not throw checked exceptions that are not thrown by the overridden method. If we allow the overriding methods in sub-classes to throw more general exceptions than the overridden method in the parent class, then the compiler has no way of checking the exceptions the sub-class might throw.

You can also relax the specification by throwing  a subset of those exceptions listed in the method's superclass or not throwing any exceptions at all in the overriding method of the subclass. You can not add new checked exception types to the overriding method.

This is only true for overriding methods not overloading methods. Thus if a method has exactly the same name and arguments it can only throw exceptions declared in the parent class, or exceptions that are children of exceptions in the parent declaration.

Basically, JVM thrown exceptions are those exceptions or errors that are either exclusively or most logically thrown by the JVM.

For example, ArrayIndexOutOfBoundsException, ClassCastException, NullPointerException, StackOverflowError, NoClassDefFoundError and many others are trown by JVM.

This kind of error and/or exception, cannot be found either by compiler or programmer, so the only way to discover it is during runtime when JVM trows it.

On the other hand, Programmatic exceptions are those exceptions that are thrown explicitly by application and/or API programmers.

For example, IllegalArgumentException, IllegalStateException, NumberFormatException, AssertionError and many others are trown explicitly by java programmers and/or API programmers.

In this case, the programmer knows exactly what kind of situation may occur and then fire and exception.

For instance, the Java API's Integer class have a method called parse() which takes a String and returns an int representing its value. So, if you pass a illegal String parameter, the API's programmer explicitly trows an IllegalArgumentException, I mean, he knows and handle a known situation programmatic.