During the execution of your program, it may experience abnormal or exceptional conditions. As a result of these, the system may crash. An exception may occur due to a number of reasons. Some of these include:
- A file that needs to be opened can’t be found.
- A client has entered invalid information.
- A system association has been lost amidst correspondences or the JVM has used up all the available memory.
Some of these special cases are created by client mistake, others by developer blunder, and others by physical assets that have fizzled into your code in some way. To see how exception handling works in Java, you have to comprehend the three classifications of exceptions:
- Errors: These are not special cases whatsoever. Therefore, errors can be defined as issues that are beyond the understanding and the ability to control of the client or the software engineer. They are normally overlooked in your code on the grounds that you can once in a while take care of a mistake. Case in point, if a stack overflow happens, it is sure to result in an error. They are additionally disregarded at the time of compiling.
- Runtime Exceptions: It is a special case that most likely could have been dodged by the software engineer. Runtime exceptions are disregarded at the time of assemblage.
- Checked Exceptions: It is a special case that is regularly a client mistake or an issue that can’t be predicted by the developer. Case in point, if a file is to be opened, yet the file can’t be found, an exception of this type happens. These special cases can’t just be disregarded at the time of compilation and dry runs.