![\"ExceptionHandling1\"](\"https:\/\/www.whizlabs.com\/wp-content\/uploads\/2014\/12\/ExceptionHandling1.jpg\")
<\/a><\/p>\n<\/p>\n
Checked exceptions:
\n<\/b>All exceptions are \u201cchecked exceptions\u201d except those under \u201cjava.lang.Error\u201d and \u201cjava.lang.RuntimeException\u201d and their sub-classes. One common example of a checked exception is when a user tries to open a file that is not present \u2013 an exception is thrown. Other examples of checked exceptions are hardware problems and common bugs. It is up to the programmer to handle these exceptions appropriately.<\/p>\n
Errors:
\n<\/b>Errors are unchecked exceptions.<\/i> Errors are conditions that usually a compiler is not expected to recover from. \u00a0These conditions occur, external to the application.\u00a0 Hence, errors are not caught by the \u201ctry-catch\u201d constructs. Thread death, IO errors are some examples of \u2018Errors\u2019.<\/p>\n
RuntimeException:
\n<\/b>Runtime exceptions are again unchecked exceptions. <\/i>They are similar to errors \u2013 in that the application is not expected to recover from Runtime exceptions. The only difference is that runtime exceptions occur within the application. Some examples of runtime exceptions are \u2018ArithmeticException\u2019, \u2018NullPointerException\u2019 etc. All sub-classes of the \u2018java.lang.RuntimeException\u2019 fall under this. It is not wrong to handle unchecked exceptions \u2013 however the compiler doesn\u2019t expect this.<\/p>\n
Handling exceptions:
\n<\/b>Having seen the different types of exceptions, we now see how an exception is handled. All exceptions are handled via the \u2018try-catch\u2019 block. The list below illustrates the syntax of a \u201ctry-catch\u201d block.<\/p>\n
try{
\n\/\/1. some code here that might raise an exception
\n}<\/p>\n
2. catch(specificException e){
\n\/\/ do appropriate action here
\n}
\ncatch(GeneralException e){
\n\/\/ do appropriate action here
\n}
\nfinally{
\n\/\/clean up code is here
\n}<\/p>\n
If the code in the \u201ctry\u201d block at line 1 produces a \u2018specificException\u2019, it will be propagated to line 2. The exception will be handled in the \u2018catch\u2019 block and the control will then move to the \u2018finally\u2019 block. Clean up code is executed in the \u201cfinally\u201d block and control moves out of the \u201ctry-catch\u201d structure.
\nEven if there are no exceptions at line 1, control will first move to the \u2018finally\u2019 block and then leave the \u201ctry-catch\u201d structure.<\/p>\n
Here are some key points regarding the \u2018finally\u2019 block:<\/p>\n
- \n
- \u2018finally\u2019 block almost<\/i> always runs.
\nIf an exception is thrown, it runs. If an exception is <\/span>not<\/i> thrown, it runs. If an exception is caught, it runs. If an exception is not caught, it runs!\u00a0(Kathy Sierra)<\/span><\/li>\n- \u2018finally\u2019 clauses are not <\/b>required.<\/li>\n<\/ol>\n
Next, we see how specific exceptions and general exceptions must be stated.
\nNow consider the following piece of code:<\/p>\n![\"ExceptionHandling2\"](\"https:\/\/www.whizlabs.com\/wp-content\/uploads\/2014\/12\/ExceptionHandling2.jpg\")
<\/a><\/p>\nHere, since we try to access the fourth element of the array, an \u2018ArrayIndexOutOfBoundsException\u2019 is thrown.\u00a0 Notice, that, the \u2018ArrayIndexOutOfBoundsException\u2019 is stated before \u2018IndexOutOfBoundsException\u2019. \u00a0In other words, specific exceptions are declared before the general one.
\n<\/b><\/p>\n<\/b>If the code was modified and the \u201cIndexOutOfBoundsException\u201d was placed before the \u201cArrayIndexOutOfBoundsException\u201d, a compiler error would result.<\/p>\n
- \u2018finally\u2019 clauses are not <\/b>required.<\/li>\n<\/ol>\n