10 Java Exception.
StackException
If you are looking at parsing the string , to interact with the stack trace ( like an IDE would do ) dont.
JDK 1.4 has a programatic stack trace access mechanism accessed through Throwabe :
Also introduced in release 1.4 is the getStackTrace() method, which allows programmatic access to the stack trace information that was previously available only in text form, via the various forms of the printStackTrace() method.
This information has been added to the serialized representation of this class so getStackTrace and printStackTrace will operate properly on a throwable that was obtained by deserialization. Catching Exceptions
Block of code is always executed despite of different scenarios:– Forced exit occurs using a return, a continue or a break statement– Normal completion– Caught exception thrownException was thrown and caught in the method– Uncaught exception thrownException thrown was not specified in any catch block in the method
Throwing Exceptions
A method is required to either catch or list all exceptions it might throw– Except for Error or RuntimeException, or their subclassesÇ If a method may cause an exception to occur but does not catch it, then it must say so using the throws keyword– Applies to checked exceptions onlyÇ Syntax: () throws { }
User-Defined Exceptions
Creating your own exceptions– Create a class that extends the RuntimeException or the Exception class– Customize the class Members and constructors may be added to the class
Checked exception
These are exceptional conditions that a well-written application should anticipate and recover from. For example, suppose an application prompts a user for an input file name, then opens the file by passing the name to the constructor for java.io.FileReader. Normally, the user provides the name of an existing, readable file, so the construction of the FileReader object succeeds, and the execution of the application proceeds normally. But sometimes the user supplies the name of a nonexistent file, and the constructor throws java.io.FileNotFoundException. A well-written program will catch this exception and notify the user of the mistake, possibly prompting for a corrected file name.
Error exception
These are exceptional conditions that are external to the application, and that the application usually cannot anticipate or recover from. For example, suppose that an application successfully opens a file for input, but is unable to read the file because of a hardware or system malfunction. The unsuccessful read will throw java.io.IOError. An application might choose to catch this exception, in order to notify the user of the problem — but it also might make sense for the program to print a stack trace and exit.
RuntimeException.
RuntimeExceptions are not checked because making you advertise them would have no effect on establishing the correctness of your methods, and would unnecessarily clutter your otherwise very readable code.
Exceptions that extend RuntimeException represent errors that you may want to handle, although you're not required to.
Unchecked Exceptions
Just as checked exceptions are useful for signaling when your methods cannot fulfill their contract, there are other errors outside of your control that can occur that prevent the Java virtual machine from fulfilling its specification, such as when memory is exhausted. Since you can't plan for such errors ahead of time, you would have to catch them everywhere, which defeats the principle of maintaining uncluttered code. Therefore, these errors are unchecked exceptions, meaning exceptions that you don't have to include in a throws clause. You are welcome to catch them (well, some of them), but the compiler won't make you do it.
ArrayStoreException
when you try to store an object in an array of incompatible type (usually occurs when using arrays of Object, since the compiler will catch any explicit type error)
NullPointerException.
All of Java's built-in run-time exceptions have two constructors: one with no parameter and one that takes a string parameter. When the second form is used, the argument specifies a string that describes the exception. This string is displayed when the object is used as an argument to print( ) or println( ). It can also be obtained by a call to getMessage( ), which is defined by Throwable.
StackException
If you are looking at parsing the string , to interact with the stack trace ( like an IDE would do ) dont.
JDK 1.4 has a programatic stack trace access mechanism accessed through Throwabe :
Also introduced in release 1.4 is the getStackTrace() method, which allows programmatic access to the stack trace information that was previously available only in text form, via the various forms of the printStackTrace() method.
This information has been added to the serialized representation of this class so getStackTrace and printStackTrace will operate properly on a throwable that was obtained by deserialization. Catching Exceptions
Block of code is always executed despite of different scenarios:– Forced exit occurs using a return, a continue or a break statement– Normal completion– Caught exception thrownException was thrown and caught in the method– Uncaught exception thrownException thrown was not specified in any catch block in the method
Throwing Exceptions
A method is required to either catch or list all exceptions it might throw– Except for Error or RuntimeException, or their subclassesÇ If a method may cause an exception to occur but does not catch it, then it must say so using the throws keyword– Applies to checked exceptions onlyÇ Syntax:
User-Defined Exceptions
Creating your own exceptions– Create a class that extends the RuntimeException or the Exception class– Customize the class Members and constructors may be added to the class
Checked exception
These are exceptional conditions that a well-written application should anticipate and recover from. For example, suppose an application prompts a user for an input file name, then opens the file by passing the name to the constructor for java.io.FileReader. Normally, the user provides the name of an existing, readable file, so the construction of the FileReader object succeeds, and the execution of the application proceeds normally. But sometimes the user supplies the name of a nonexistent file, and the constructor throws java.io.FileNotFoundException. A well-written program will catch this exception and notify the user of the mistake, possibly prompting for a corrected file name.
Error exception
These are exceptional conditions that are external to the application, and that the application usually cannot anticipate or recover from. For example, suppose that an application successfully opens a file for input, but is unable to read the file because of a hardware or system malfunction. The unsuccessful read will throw java.io.IOError. An application might choose to catch this exception, in order to notify the user of the problem — but it also might make sense for the program to print a stack trace and exit.
RuntimeException.
RuntimeExceptions are not checked because making you advertise them would have no effect on establishing the correctness of your methods, and would unnecessarily clutter your otherwise very readable code.
Exceptions that extend RuntimeException represent errors that you may want to handle, although you're not required to.
Unchecked Exceptions
Just as checked exceptions are useful for signaling when your methods cannot fulfill their contract, there are other errors outside of your control that can occur that prevent the Java virtual machine from fulfilling its specification, such as when memory is exhausted. Since you can't plan for such errors ahead of time, you would have to catch them everywhere, which defeats the principle of maintaining uncluttered code. Therefore, these errors are unchecked exceptions, meaning exceptions that you don't have to include in a throws clause. You are welcome to catch them (well, some of them), but the compiler won't make you do it.
ArrayStoreException
when you try to store an object in an array of incompatible type (usually occurs when using arrays of Object, since the compiler will catch any explicit type error)
NullPointerException.
All of Java's built-in run-time exceptions have two constructors: one with no parameter and one that takes a string parameter. When the second form is used, the argument specifies a string that describes the exception. This string is displayed when the object is used as an argument to print( ) or println( ). It can also be obtained by a call to getMessage( ), which is defined by Throwable.
