exception2

16. Exception Hierarchies

16.1 Throw Clauses

If a method can throw either a certain exception A, or any subclasses of A (Asub), then it is enough to declare in the method declaration that the method throws A. It is then allowed to throw subclasses of A from the method too.

You are allowed to declare the subclasses in the throws clause of the method, even if you don't really need to. It can make the code easier to read and understand for the next developer to look at it. Here is an example

public void doSomething() throws IOException, FileNotFoundException{
}

As long as the superclass of any declared exception is also declared thrown, it doesn't have any effect on the code to include the throwing of the subclass. In the example above it has no real effect that FileNotFoundException is declared thrown when IOException is also declared. When you catch IOException you also catch FileNotFoundException. It is still possible to handle the two exceptions with each their own catch-block as shown earlier, even if only the superclass is declared thrown.

16.2 Designing Exception Hierarchies

http://tutorials.jenkov.com/java-exception-handling/exception-hierarchies.html

17. Exception Wrapping

http://tutorials.jenkov.com/java-exception-handling/exception-wrapping.html

Exception wrapping is wrapping is when you catch an exception, wrap it in a different exception and throw that exception. Here is an example:

try{
    dao.readPerson();
}catch (SQLEXception sqlException){
    throw new MyException("error text", sqlException);
}

17.1 Why use Exception Wrapping?

There are two main reasons for this.

1) Declared exceptions aggregate towards the top of the call stack. If you do not wrap exceptions, but instead pass them on by declaring your methods to throw them, you may end up with top level methods that declare many different exceptions. Declaring all these exceptions in each method back up the call stack becomes tedious.

2) You may not want your top level components to know anything about the bottom level components, nor the exceptions they throw. For instance, the purpose of DAO interfaces and implementations is to abstract the details of data access away from the rest of the application. Now, if your DAO methods throw SQLException's then the code using the DAO's will have to catch them. What if you change to an implementation that reads the data from a web service instead of from a database? Then you DAO methods will have to throw both RemoteException and SQLException. And, if you have a DAO that reads data from a file, you will need to throw IOException too. That is three different exceptions, each bound to their own DAO implementation.

To avoid this your DAO interface methods can throw DaoException. In each implementation of the DAO interface (database, file, web service) you will catch the specific exceptions (SQLException, IOException, RemoteException), wrap it in a DaoException, and throw the DaoException. Then code using the DAO interface will only have to deal with DaoException's. It does not need to know anything about what data access technology is used in the various implementations.

18. Fail Safe Exception Handling

The last exception thrown in a try-catch-finally block is the exception that will be propagated up the call stack.

* All earlier exceptions will disappear.*

One way to avoid the first exception thrown disappear is to make sure that the last exception thrown contains all previously thrown exceptions. That way they are all available to the developer investigating the error cause. This is how our Java persistence API, Mr Persister, implements transaction exception handling.

19. Pluggable Exception Handlers

to be continue...

20. Logging Exceptions:

to be continue

21. Validation

http://tutorials.jenkov.com/java-exception-handling/validation-throw-exception-or-return-false.html

to be continue

22. Exception Handling Templates in Java

23. Exception Enrichment in Java

Exception enrichment is an alternative to exception wrapping.

24. Execution Context

http://tutorials.jenkov.com/exception-handling-strategies/execution-context.html

25 quiz in Javatpoint

1. What will be the output of the program?

public class Foo{
    public static void main(String[] args){
        try{
            return;
        }
        finally{
            System.out.println("Finally!");
        }
    }
}

output: Finally!

Description:

If you put a finally block after a try and its associated catch blocks, then once execution enters the try block, the code in that finally block will definitely be executed except in the following circumstances:

1. An exception arising in the finally block itself.

2. The death of the thread.

3. The use of System.exit()

4. Turning off the power to the CPU.

I suppose the last three could be classified as VM shutdown.

2. Say that methodA calls methodB, and methodB calls methodC. MethodC might throw a NumberFormatException. Can the program be written so that methodA handles the exception?

YES. If the headers for methodC and methodB say... throws NumberFormatException.

3. What happens in a method if an exception is thrown in a try{} block and there is NO MATCHING catch{} block?

The method throws the exception to its caller, exactly if there were no try{} block.

4. Which statement is FALSE about catch{} block?

The catch{} block for a child exception class must FOLLOW that of a parent exception class.