top of page
Coding Guru
​
1 Introduction
- An unwanted unexpected event that distributes normal flow of the program is called exception Example sleepingException, TyrePuncturedException, FileNotFoundException.
- It’s highly recommended to handle exception
- The main objective of exception handling is graceful termination of the program.
- Exception handling doesn’t mean repairing an exception we have to define alternative way to continue rest of the program normally.
- For example if our programming requirement is to read the data from London file at runtime if London file is not available our program shouldn’t be terminated abnormally we have to provide local file to continue rest of the program normally. This way of defining alternative is nothing but exception handling.
try {
Read data from London file
}catch (FileNotFoundException e){
Use local file and continue rest of the program normally
}
2 Runtime stack mechanism
- For every thread J.V.M will create one runtime stack every method call performed by that thread will be stored in to the corresponding stack each entry in the stack is called one activation record or stack frame.
- After completing every method the corresponding entry from the stack will be removed.
- After completing all method calls the empty stack will be destroyed by J.V.M and the program will be terminated normally.
Class Test {
p. s. v. m (String args []) {
doStuff ();
}
}
3 Default Exception Handling:
---If any Exception raised, the Method in which it is raised is responsible to create the Exception by creating the Exception Object.
---Name of the Exception
---Description of the Exception
---Location of the Exception
---After calling Exception Object, the Method Handovers the Exception Object to the J.v.m.
---J.v.m checks whether the method contains any Exception handling code or not.
---If the Method contains any Exception handling code will be Executed, and continue rest of the program normally.
---if the Method does not contain any Exception handling code then the program terminates abnormally, and the J.v.m removes the program abnormally from the stack.
---J.v.m Identifies the Caller Method and checks whether the caller method contain any handling code or not .if the caller method does not contain the handling code the J.v.m terminates the caller method abnormally and removes it s entry from the stack.
---this process will continue until main ().If the main also does not contain the handling code the J.v.m will terminates the main abnormally and removes its entry from the stack.
---just before terminating the program abnormally the J.v.m handovers the responsibility of the Exception handling to the default Exception handler.
---Default Exception handler just print the Exception information to the console in one of the following formats
Name of the Exception: Description
Location (stack Trace)
Class Test {
Public static void main (String argsP[])
{
Dostuff ();
}
Public .static.void.doStuff ()
{
domoreStuff ();
}
Public .static.void.domoreStuff ()
{
System.out.Println (10/0);
}
}
Exception in thread “main “:java.lang.AE:/by Zero
Name of Exception with Description
Runtime Stack
At Test.domoreStuff
At Test.doStuff
At Test.Main
4 Exception Hierarchy:
-
--Throwable class acts as the root for the Entire java Exception Hierarchy.
-
---It has two child classes.
-
Exception---In Most of the cases Exceptions are caused by our program and these are Recoverable.
-
Error---In Most of the cases Errors are not caused by our program these occur due to the lack of Resources and these are Non-Recoverable.
-
Checked Vs Un-Checked---The Exceptions which are checked by compiler for the Smooth Execution of the Program are called as Checked Exceptions.
Ex:
------HallTicketMissingException
------PenNotFoundException
------FileNotFoundException
------The Exceptions which are not checked by the compiler are called as Un-Checked Exceptions.
Ex:
------BombBlastException
------ArithmaticException
---Whether the Exception is Checked or Un-Checked Exception it should be Run-time Exception Only. There is no chance of Occurring at -
Compile-time.---Runtime Exceptions and its Child classes Errors and its child classes are Checked Exceptions and all the Remaining are Un-Checked Exceptions.
-
Partially Checked Vs Fully Checked---The Checked Exception is said to be Fully Checked if all its child classes are also checked.Ex:
-
------IOException.
---The checked Exception is said to be Partially Checked if some of its child classes are Un-Checked.
Ex:
------Exception.Which of the Following are Checked?
Ans:
IOException :Fully-Checked
Error :Un-checked
Throwable :Partially Checked
NullpointerException :Un-checked
InterruptedIOException :Fully-Checked
SQlException :Fully-Checked
Note::
---In java partially Checked Exceptions are Exception and Throwable.
5 Customized Exception handling by try-catch
---we can maintain the risky code inside the try block and the corresponding handling code in the catch block.
Try{
Risky code;
}
Catch(xxx e)
{
Handling code;
}
Ex:
Class Test
{
Public static void main(String args[]){
System.out.println(“state1”);
System.out.println(10/0);
System.out.println(“state3”);
}
}
Output:
State1
R.E:A.E:1 by Zero
Abnormal Termination
Class Test{
Public static void main(String args[])
{
System.out.println(“state1”);
Try {
System.out.println(10/0);
}
Catch(AE e) {
System.out.println(10/2);
}
System.out.println(“state3”);
}
}
Output:
State1
5
State3
Normal Termination.
6 Control Flow in try-catch
Try {
State1;
State2;
State3;
}
Catch(ArithmeticException e) {
State4;
}
State5;
Case1:
If there is no exception state 1,2,3,5 are normal terminations.
Case2:
If the Exception raised at statement 2 and corresponding catch block is matched statement1,4,5 are normal Terminations.
Case3:
If the Exception is raised at statement 2 and corresponding catch block is not matched statement1 with abnormal Termination.
Case4:
If the Exception is raised at statement 4 or statement 5 it is always a abnormal Termination.
Note:
Within the Try block if any where there is an Exception, the rest of the Try block won’t be Executed even though we handled that exception. Hence it is recommended to take the Risky code within the try block and length of the try should be as less as possible.
If there is an Exception in any other statement which is not a part of try block then it always results in abnormal Termination.
7 Methods to print Exception Information
Throwable class defines the following methods to print Exception Information.
7.1. PrintStackTrace():
---This method prints the Exception Information in the Following Format.
Name of the Exception:Description
Stacktrace
7.2. toString():
---It prints Exception Information in the Following Format.
Name of the Excception:Description
7.3. getMessage():
---This method prints the Description of the Exception.
Description
Ex:
Class Test
{
Public static void main(String args[])
{
Try {
System.out.println(10/0);
}
Catch(AE e) {
e.printstackTrace();
System.out.println(e);
System.out.println(e.getMessage());
System.out.println(e.toString());
}
}
}
Note1:
Default ExceptionHandler uses PrintStackTrace().
8 Try with Multiple Catch Blocks
---The way of handling an Exception is varied from Exception to Exception.Hence for Every Exception it is Recommended to take Separate Catch block.
Ex:
Try {
---------------------
-----------------------
}
Catch(Exception e) {
---------------------
------------------------
}
Ex:2:
Try {
--------------
---------------
}
Catch(ArithmeticException e)
{ Perform these Arithmetic Operations.
}
Catch(FileNotFoundException e)
{
Use localFile;
}
Catch(NullpointerExeption e)
{
Use AnotherResource;
}
Catch(Exception e)
{
Default ExceptionHandler;
}
---Hence try with Multiple Catch Blocks is Possible and hence it is Highly recommended to use.
---If try with Multiple Catch blocks is present the order of the catch blocks is important and it should be from child to parent.
---If we are trying to keep the Catch blocks from parent to child then there will be a compiler error saying that “Excception xxxx has already been caught”.
Child to parent is follows
Try Try
{ {
---------------------- ----------------------
----------------------- ----------------------
} }
Catch(Exception e) Catch(ArithmeticException e)
{ {
----------------------- ----------------------
------------------------ ----------------------
} }
Catch(ArithmeticException e) Catch(Exception e)
{ {
--------------------------- ----------------------
--------------------------- -----------------------
} }
Output:
Exception java.lang.AE.has already been caught.
9 Finally Block
---It is never Recommended to define clean-up code with in the Try Block because there is no guarantee for the Execution of Every Statement.
---It is never Recommended to define the clean-up code within the catch block,because it wont be executed if there is no exception.
---We require a place to maintain the clean-up code which should be executed always irrespective of whether exception raised or not raised and handle or not handle,such type of place is nothing but finally block.
---Hence the main purpose of the finally-block is to maintain the clean-up code which should be Executed always.
Ex:
Class Test Class Test Class Test
{ { {
P s v m(String args[]) P s v m(String args[]) P s v m(String args[])
{ { {
Try Try Try
{ { {
S.o.pln(“try”); S.o.pln(“try”); S.o.pln(“try”);
} S.o.pln(10/0); S.o.pln(10/0);
Catch(AE e) } }
{ Catch(AE e) Catch(Npe e)
S.o.pln(“catch”); { {
} S.o.pln(“catch”); S.o.pln(“catch”);
Finally } }
{ Finally Finally
S.o.pln(“finally”); { {
}}} S.o.pln(“finally”); S.o.pln(“finally”);
Output: }}} }}}
Try Output: Output:
Finally Try Try
Catch Finally
Finally Abnormal Termination.
9.1 Return Vs Finally:
---finally block dominates the return statement also. Hence if there is any return statement present inside the try or catch block first finally will be executed and then return statement will be executed.
Ex:
Class Test
{
p.s.v.m(String args[])
{
Try
{
S.o.pln(“try”);
return;
}
Catch(AE e)
{
S.o.pln(“catch”);
}
Finally
{
S.o.pln(“finally”);
}
}
}
Output:
Try
Finally.
---There is only one situation where finally block won’t be executed is whenever J.v.m shutdown. i.e.,whenever we are using System.exit(0);
Ex:
Class Test
{
p.s.v.m(String args[])
{
Try
{
S.o.pln(“try”);
System.exit(0);
}
Catch(AE e)
{
S.o.pln(“catch”);
}
Finally
{
S.o.pln(“finally”);
}
}
}
Output:
Try
10 Difference between final ,finally and finalize:
10.1. Final:
--It is the modifier applicable for classes,methods and variables.
--If a class is declared as final child class declaration is not possible.
--If a method is declared as final then overriding of that method is not possible.
--if a variable is declared as final then reassignment of that variable is not possible because that is a constant.
10.2. Finally:
--It is the block associated with try-catch block to maintain the clean-up code which should be executed irrespective of whether exception raised or not raised and whether handled or not-handled.
10.3. Finalize():
--It is the method which should be executed by garbage-collector before destroying any object to perform clean-up activities.
Note:
--When compare with finalize(),it is highly recommended to use finally block to maintain clean-up code because we can’t except exact behaviour of the garbage collector.
11 Various Possibilities of Try-catch-Finally:
Try Try Try Try Try Try
{ { { { { {
} } } } } }
Catch(xxx e) Catch(AE e) Catch(AE e) Catch(xxx e) Catch(AE e) Finally
{ { { { { {
} S.opln(“Hello”); } } } }
S.opln(“Hello”); } Finally Catch(AE e) Catch(Exception e)
{ { { } } }
Try Catch(XXX e) Finally
{ { {
} } }
C.E: C.E: C.E:
Try without catch and finally. Catch without try. Finally without try and catch.
Try Try
{ {
} }
Catch(XXX e) Catch(AE e)
{ {
} }
S.o.Pln(“Hello”); Finally
Finally {
{ }
} Finally
{ }
C.E:
Finally without Try.
Try Try
{ {
} }
Catch(AE e) Catch(Exception e)
{ {
} }
Catch(AE e) Catch(AE e)
{ {
} }
C.E:
Exception java.alng.AE.has already been caught.
Try Try
{ {
} Try
Catch(XXX e) {
{ }
} }
Finally Catch(AE e)
{ {
Try }
{ C.E:
} Try without Catch or Finally.
Catch(AE e)
{
}
}
Try
{
}
Finally
{
}
Catch(AE e)
{
}
C.E:
Catch Without Try.
12 Control Flow in Try-Catch-Finally:
Try
{
State1;
State2;
State3;
}
Catch(AE e)
{
State4;
}
Finally
{
State5;
}
State6;
Case1:
If there is no Exception, then statement 1,2,3,5,6 normal Execution.
Case2:
If the Exception is Raised at Statement 2 and Corresponding catch-block matched then statement 1,4,5,6 normal Execution.
Case3:
If the Exception is Raised at Statement 2 and the Corresponding Catch-block not matched then statement 1,5 abnormal Execution.
Case4:
If the Exception is Raised at Statement 4 then it is always an abnormal Execution,but before that finally block must be Executed.
Case5:
If the Exception is Raised at statement 5,statement 6 ,then it is always an abnormal Execution.
13 Control-flow in Nested try-Catch-Finally:
Try{
State1;
State2;
State3;
Try
{
State4;
State5;
State6;
}
Catch(AE e) {
State7;
}
Finally {
State8;
}
State9;
}
Catch(xxx e){
State10;
}
Finally{
State11;
}
Case1:
If there is no Exception,State1,2,3,4,5,6,8,9,11,12 normal Execution.
Case2:
If the Exception is Raised at Statement2 ,and corresponding Catch block matched then Statement 1,10,11,12 Normal Execution.
Case3:
If the Exception is Raised at Statement 2 and corresponding catch-block not matched then Statement 1,11 abnormal Execution.
Case4:
If the Exception is Raised at Statement 5 and inner block Catch-block matched then Statement 1,2,3,4,7,8,9,11,12 normal Execution.
Case5:
If the Exception is Raised at Statement 5 and Inner Catch-block not matched and outer Catch-block matched then Statement 1,2,3,4,8,10,11,12 normal Execution
Case6:
If the Exception is Raised at Statement 5 and inner and Outer Catch-blocks not matched then Statement 1,2,3,4,8,11 abnormal Execution.
Case7:
If the Exception is Raised at Statement 7 and corresponding Catch blocks are matched then Statement 1,2,3,4,5,6,8,10,11,12 normal Execution.
Case8:
If the Exception is Raised at Statement 7 and corresponding Catch-block not matched then Statement 1,2,3….,8,11, are abnormal Execution.
Case9:
If the Exception is Raised at Statement 8 and corresponding Catch-block matched then statement 1,2,3,…,8,11,12, normal Execution.
Case10:
If the Exception is Raised at Statement 8 and the Corresponding Catch-block not matched then Statement 1,2,3,……11 normal Execution.
Case11:
If the Exception is Raised at Statement 9 and Corresponding Catch block Matched then Statement 1,2,3,…,8,10,11,12 normal Execution.
Case12:
If the Exception is Raised at Statement 9 and the Corresponding Catch block not matched then Statement 1,2,3,….,8,11 abnormal Execution.
Case13:
If the Exception is Raised at Statement 10 it is always abnormal Termination but before that finally block must be Executed.
Case14:
If the Exception is Raised at Statement 11 and Statement 12 then it is always abnormal Termination.
14 THROW:
---Sometimes we can create Exception Object Manually, and hand-over the object Explicitly to the J.v.m
Explicitly by using throw Keyword.
Throw new ArithmaticException(“/by zero”);
---Hence the MainPurpose of Throw Keyword is to handover created Exception object manually to the J.V.M.
---The Result of the following two programs is Exactly the same.
Ex:
Class Test class Test
{ {
p.s.v.m(String args[]) p.s.v.m(String args[])
{ {
S.o.pln(10/0); Throw new ArithmaticException(“/by zero”);
} }
} }
In the First Case A.E is created internally and hand-over that object automatically by the main().
In the Second Case we created the A.E object and we are hand-over it to the J.v.m manually by throw keyword.
In general we use throw keyword for customized exceptions.
Case1:
---If we are trying to throw null reference we will get null pointer exception.
Class Test Class Test
{ {
Static A.E e; static A.E e=new A.E();
p.s.v.m(String args[]) p.s.v.m(String args[])
{ {
Throw e; Throw e;
} }
} }
R.E:NPE R.E:A.E
Case2:
After throw statement we are not allowed to write any statement otherwise we will get an compiletime error saying that “unreachable Statement”.
Class Test class Test
{ {
p.s.v.m(String args[]) p.s.v.m(String args[])
{ {
S.o.pln(10/0); Throw new ArithmaticException(“/by zero”);
S.o.pln(“Hello”);} S.o.pln(“Hello”);}
} }
R.E:A.E/zero C.E: unreachable Statement
Case3:
We can use throwable keyword only for throwable type otherwise we will get an compile time error saying “incompatible types”.
Class Test class Test extends RuntimeException
{ {
p.s.v.m(String args[]) p.s.v.m(String args[])
{ {
Throw new Test(); Throw new Test();
} }
} }
C.E: R.E:
Incompatible types Exception In thread main test.
Found Test
Required java.lang.Throwable
15 Throws:
---In our program if there is any chance of raising an checked Exception then we should compulsory handle it otherwise we will get compiletime error says “unreported Exception xxxx must be caught or declare to be thrown.
Ex:
Class Test
{
P.s.v.m(String args[])
{
Thread.sleep(100);
}
}
C.E:
Unreported Exception java.lang must be caught
---We can handle this by two-ways:
1. by using try-catch.
2. by using throws.
1. by using Try-catch:
Class Test
{
P.s.v.m(String args[])
{
Try
{
Thread.sleep(5000);
}
Catch(I.E e)
{
}
}
2. by using throws keyword:
Class Test
{
P.s.v.m(Strring args[]) throws I.E
{
Thread.sleep(5000);
}
}
---we can use the throws keyword to delegate the Responsibility of Exception handling to caller method.
---We can use the throws keyword inorder to delegate the Responsibility of Exception handling to caller method in the case of checked exception to convence compiler.
---In the case of un-checked Exceptions it is not necessary to use the throws keyword.
Ex:
Class Test
{
P.s.v.m(String args[]) throws I.E
{
doStuff();
}
P.s.v.doStuff() throws I.E
{
doMoreStuff();
}
P.s.v.doMoreStuff() throws I.E
{
Thread.sleep(5000);
}
}
---In the above program if we are removing the throws keyword the code won’t be compiled, so we need all the 3 throws keywords.
---we should use the throwable keyword only for the throwable types otherwise we will get incompatible types compile time error.
Ex:
Class Test
{
P.s.v.m (String args[]) throws test
{
}
}
C.E:
Incompatible type
Found: test
Required java.lang.throwable
Program should be in the following way:
Class Test extends Exception
{
P.s.v.m (String args[]) throws Test
{
}
}
Case1:
Checked:
Class Test
{
P.s.v.m (String args [])
{
Throw new Exception ();
}
}
C.E:
Un-reported Exception java.lang must be caught at declared to be thrown.
Note:
As Exception is checked we should handle it compulsorily either by try-catch or by throws keyword.
Case2:
Un-checked:
Class Test
{
P.s.v.m (String args [])
{
Throw new error ();
}
}
R.E:
Exception in thread “main” java.lang. Error.
Note:
An Error is Un-checked it is not required to handle by try-catch or throws.
Case2:
In our program if there is no chance of raising an Exception then we can’t define the Catch-block for that Exception. Otherwise, we will get compile time Error but this rule is only applicable for fully-checked Exceptions.
Ex:
Try
{
S.o.pln (“hello”);
}
Catch (Exception e)
{
}
Output:
Hello
Try
{
S.o.pln (“hello”);
}
Catch (ArithmaticException e)
{
}
Output:
Hello
Try
{
S.o.pln (“hello”);
}
Catch (IOException e)
{
}
C.E:
Exception java.lang.IOE.is never thrown in body of corresponding try statement.
Try
{
S.o.pln (“hello”);
}
Catch (InterruptedException e)
{
}
C.E:
Exception java.lang.IE.is never thrown in body of corresponding try statement.
Try
{
S.o.pln (“hello”);
}
Catch (Error e)
{
}
Output:
Hello
Keywords for Exception:
Try
Catch
Finally
Throw
Throws
16 Exception Handling Keywords Summary:
Try: Risky code
Catch: To Maintain Handling Code
Finally: To Maintain Clean-up Code
Throw: To hand-over our created Exception Object to the J.v.m manually.
Throws: To delegate the Responsibility.
17 Various Possible Compile-time Errors in Exception Handling:
1. Exception xxx has already been caught.
2. Unreported Exception xxx must be caught or declared to be thrown.
3. Exception xxx is never thrown in the body of the try statement.
4. Try without catch or finally.
5. Finally without try.
6. Catch without try.
7. Unreachable statement
8. Incompatible types.
Found: Test
Required: java . Lang. throwable.
18 Customized Exceptions:
Sometimes to meet our programming Requirements we create our own Exceptions.Suchtype of Exceptions are called Customized Exceptions.
Ex: tooYoungException, tooOldException , InsufficientFoundsException etc.,
Ex:
Class tooYoungException extends RuntimeException
{
TooYoungException(String s)
{
Super(s);
}
}
Class tooOldException extends RuntimeException
{
TooOldException(String s)
{
Super(s);
}
}
Class Test
{
P.s.v.m (String args[])
{
Int age=Integer.parseInt (args[0]);
If (age>60)
{
Throw new tooOldException (“please wait some more time or age is already crossed marriage age”);
}
Else if (age<18)
{
Throw new tooYoungException (“no chance of getting married”);
}
Else
{
S.o.pln (“you will get match details by mail”);
}
}
}
Note:
It is always recommended to always keep our Customized Exception class Un-checked. That is we have to extend the run-time Exception class but not the Exception class while defining our customized exceptions.
19 Top-10 Exceptions:
--- Based on the Source who triggers the Exceptions, all Exceptions are divided into Two-types.
1. J.v.m. Exceptions.
2. Programmatic Exceptions.
19.1.J.v.m. Exceptions:
--- The Exceptions which are Raised by the J.v.m whenever a particular Event Occurs are called J.V.M Exceptions.
Ex:
ArrayIndexOutOfBoundsException
NullPointerException .
19.2. Programmatic Exceptions:
---The Exceptions which are Explicitly Raised by the Programmer or the API Developer are called Programmatic Exceptions.
Ex:
IllegalArgumentException
NumberFormatException
19.1.1 ArrayIndexOutOfBoundsException:
--- It is child class of Runtime Exception and hence it is Un-checked, it is Raised automatically by the J.v.m, whenever we are trying to access array element without range index.
Ex:
Int a=new Int [10];
S.o.pln (a[0]); 0
S.o.pln (a[100]);AIOOBE
19.1.2.NullPOinterException:
---It is the child class of Runtime Exception and hence it is Un-checked. It is raised automatically by the J.v.m whenever we are trying to perform the Operation on Null.
Ex:
String s=Null;
S.o.pln (s.length ()); NPE
19.1.3.StackOverFlowError:
---It is the Child class of Error and hence it is Un-checked. It is raised automatically by the J.v.m whenever we are trying to Perform Recursive Method Invocation.
Ex:
Class Test
{
P.s.v.m m1 ()
{
M2 ();
}
P.s.v.m m2 ()
{
M1 ();
}
P.s.v.m (String args[])
{
M1 ();
}
}
R.E: SOE
19.1.4. NoClassDefFoundError:
---It is the Child class of Error and hence it is Un-checked. It is Raised automatically by the J.v.m whenever J.v.m unable to find required class
Java Srinu
R.E: NCDFE
19.2.1. ClassCastException:
---It is the Child class of Runtime Exception and hence it is Un-checked. It is Raised automatically by the J.v.m whenever we are Trying to Type-cast parent-type object to child-type.
Ex:
String s=new String (“Durga”);
Object o= (object) s;
Object o=new Object ();
String s= (string) o;
R.E: CCE
19.2.2.ExceptionInInitializerError:
---It is the Child class of Error and hence it is Un-checked. It is raised automatically by the J.v.m, if any Exception occurs while performing initialization for static variables and while executing static blocks.
Ex:
Class Test
{
Static Int i=10/0;
}
R.E: EIIE
19.2.3.IllegalArgumentException:
------It is the Child class of Runtime Exception and hence it is Un-checked. It is Explicitly Raised by the Programmer or API Developer to indicate that a method has been invoked with invalid argument.
Ex:
Thread t=new Thread ();
t.setPriority (10);
t.setPriority (100);
R.E: IAE
19.2.4.NumberFormatException:
------It is the Child class of Runtime Exception and hence it is Un-checked. It is Explicitly Raised by the Programmer or API Developer to indicate that we are trying to convert String to Number Type but the String is not properly formatted.
Ex:
Int a=Integer.parseInt (“10”);
Int a=Integer.parseInt (“ten”);
19.2.5.IllegalStateException:
------It is the Child class of Runtime Exception and hence it is Un-checked. It is Explicitly Raised by the Programmer or API Developer to indicate that we are trying a method which has been invoked at appropriate time.
Ex:
Once the Session Expires we can’t call any method on that object otherwise we will get IllegalStateException.
EX:
HttpSession Session=Req.getSession ();
S.o.pln (Session.getId ());
1234
Session. Invalidate ();
S.o.pln (Session.getId ());
Ex2:
Thread t=new thread ();
t.start ();
.
.
.
.
t.start ();
R.E: ITSE
---after restarting the thread we are not allowed to restart the same thread. Otherwise we will get runtime exception.
19 .2.6.Assertion Error:
------It is the Child class of Runtime Exception and hence it is Un-checked. It is Explicitly Raised by the Programmer or API Developer to indicate that assert statement fails.
Ex: Assert (false);
R.E:
Assertion Error
Exception/error Raised by
1. AIOOBE J.V.M
2. NPE J.V.M
3. SOFE J.V.M
4. NCDFE J.V.M
5. CCE J.V.M
6. EIIE J.V.M
7. IAE Programmer/Api developer
8. NFE Programmer/Api developer
9. ISE Programmer/Api developer
20 Exception Propagation:
The process of delegating the Responsibility Exception Handling from one method to another method by using throws keyword Is called Exception Propagation.
-
------Exception -
-------Error.
EXCEPTION HANDLING
bottom of page