Which standard java exception classes extend java.lang.RuntimeException?
1.SecurityException: It is thrown by the security manager upon security violation. For example, when a java program runs in a sandbox (such as an applet) and it tries to use prohibited APIs such as File I/O, the security manager throws this exception.
Since this exception is explicitly thrown using the new keyword by a security manager class, it can be considered to be thrown by the application programme
2.ClassCastException extends RuntimeException: Usually thrown by the JVM. Thrown to indicate that the code has attempted to cast an object to a subclass of which it is not an instance. For example, the following code generates a ClassCastException:
Object x = new Integer(0);
System.out.println((String)x);
3.NullPointerException extends RuntimeException: Usually thrown by the JVM. Thrown when an application attempts to use null in a case where an object is required. These include:
Calling the instance method of a null object.
Accessing or modifying the field of a null object.
Taking the length of null as if it were an array.
Accessing or modifying the slots of null as if it were an array.
Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other illegal uses of the null object.
4.IndexOutOfBoundsException extends RuntimeException:
Usually thrown by the JVM. Thrown to indicate that an index of some sort (such as to an array, to a string, or to a vector) is out of range. Applications can subclass this class to indicate similar exceptions.
ArrayIndexOutOfBoundsException and StringIndexOutOfBoundsException both extend IndexOutOfBoundsException.
5.IllegalArgumentException extends RuntimeException: If a parameter passed to a method is not valid. Usually thrown by the application.
6.IllegalStateException extends RuntimeException: Signals that a method has been invoked at an illegal or inappropriate time. In other words, the Java environment or Java application is not in an appropriate state for the requested operation. Usually thrown by the application.
TRY-CATCH
If there is no appropriate catch block, the exception will be thrown further on.
‘finally’ block is always executed (even if there is a return in try but not if there is System.exit() )
TRY with resources
Syntax: try(resource declarations)
- A resource is an object that must be closed after the program is finished with it. Any object that implements java.lang.AutoCloseable, which includes all objects which implement java.io.Closeable, can be used as a resource.
*the resources will be closed regardless of whether the try statement completes normally or abruptly
*the close methods of resources are called in the opposite order of their creation!
- In a try-with-resources statement, any catch or finally block is run after the resources declared have been closed.
Propagation of exceptions: if an exception is thrown from both the try block and the finally block/try-with-resources statement
*FINALLY: the exception the finally block is thrown and the exception thrown from the try block is suppressed
VS
*TRY WITH RESOURCES: the exception from the try block is thrown and the exception thrown from the try-with-resources block is suppressed.
*You can retrieve these suppressed exceptions by calling the Throwable.getSuppressed method from the exception thrown by the try block.
- try with resources is preferred over finally, because closing resource in finally can cause resource leaks!!!
A program has to do more than rely on the garbage collector (GC) to reclaim a resource’s memory when it’s finished with it. The program must also release the resoure back to the operating system, typically by calling the resource’s close method. However, if a program fails to do this before the GC reclaims the resource, then the information needed to release the resource is lost. The resource, which is still considered by the operating system to be in use, has leaked.
*See the Javadoc of the AutoCloseable and Closeable interfaces for a list of classes that implement either of these interfaces. The Closeable interface extends the AutoCloseable interface. The close method of the Closeable interface throws exceptions of type IOException while the close method of the AutoCloseable interface throws exceptions of type Exception. Consequently, subclasses of the AutoCloseable interface can override this behavior of the close method to throw specialized exceptions, such as IOException, or no exception at all.
TYPE of exceptions
*CHECKED exceptions: who should be trated in the program and for which the recovery is excepted
* UNCHECKED exceptions and their subclasses(are not to be catheds or thrown):
**RuntimeExceptions: internal to application (bugs, logic errors, improper use of an API: eg: NullPointerException)
**Error: external to the applications(eg: hardware and system errors)
All exception classes are descendants of the Throwable class
java.lang.Object
java.lang.Throwable
All Implemented Interfaces:
Serializable
Direct Known Subclasses:
Error, Exception
You can throw an unchecked exception from a methos without declaring it in the methods signature!!
Checked exception
=an exception that is not a subclass of Error or RuntimeException!!!
A method that throws a “checked” exception –> either must declare it in throws clause or put the code that throws the exception within a try/catch block.e
If the reference to the exception is null–> the throw will throw a NPE(NullPointerException)
