JAVA exception

Overall types

Object --> Throwable --> Exception

                                   --> Error

 

Error is not usually used in app. It can be the errors thrown by JVM.

 

Two types of exceptions - checked exception and run time exception.

Checked exception is the one we use/create in our app. The exceptions that we are certain our method will throw. For example, the method or API clearly states the exception it might throw, that's checked exception. The exceptions mentioned by 'Throws' of the method must be the checked exceptions. AND that must be a checked exception if your app creates your own exception type.

On the other hand, that's the run time exception. e.g. the out of bound index, or divid by 0. That occurs in runtime.

 

checked exception means the ones (exceptions) that can be checked by the compiler. that's why we call it 'checked exception'. So you know them in the compiling phase.

We don't need to state the runtime exception to throw for a method, because every method can throw a runtime exception.don't need then.

 

sync exception and async exception

Almost all exceptions we experience in our app are the sync exception. We are sure that exception occurs on the execution of one certain code/instruct.

async exception are usually from JVM in an async way with your app.

 

Usage

If we implement or override a method that declares(throws) checked exceptions, our implementation cannot throw more exceptions than what are declared (there can be application code already to handle the exceptions for the abstract code).

And we cannot throw more generic exceptions than that are declared but we can throws the specific(sub type) exception.

if our implementation code doesn't need to  throw an exception, it's ok that we don't throw any.

catch

There can be 0 or multiple catches after a try. But at least either catch or finally has to be there after the try.

If the exception doesn't match any 'catch' (i.e. the catches fail to catch the exception), the exception has to go out and see if the outter catch can catch it.

finally

the finallay part always executes. Even if you 'return' before reaching the finally part, the finally still executes before the method really returns. However if some code is after the finally, the finally executes firstly.

exception

exception consists of "message" +"cause". Message is a text; cause is a throwable (can be init to or pointing to another exception).

When we catch an exception and we want to throw a new exception, we shall 'throw new exception(<the catched exception>). By this way,  the original exception is not swallowed and it's used to construct the 'cause' of the new exception. This is the recommended way.

 

runtime exception

Usually we don't need to try and catch the runtime excepition. It's the program error to cause the runtime exception.

if the checked-exception is not try and catched, that will cause the compiling error. That's why it's so called 'checked' exception.

If we throw a checked exception, we have to declare the 'throws' and the caller has to try and catch it. The bug will look ugly. One suggestion is to wrap it to be a runtime exception and throw the runtime exception. Then you don't have to declar it and the caller doesn't have to try and catch and code will be cleaner.

Added later

check-exception can also mean the exceptions that we are forced to check.

When we think when the exception occurs, we can recover, we shall use check-exception; otherwise, or we are certain if that can be recovered, we use unchecked exception (runtime exception).

If it's the unchecked exception, we are not forced to "catch" the exception in programming.