"The point of a checked exception is to force code to deal with potential issues that can be reasonably anticipated (such as the unavailability of a file). However, from another point of view checked exceptions represent the exact opposite goal of error handling. Namely, that a function or code block can and should inform the calling function that an error has occurred, but not explicitly make a decision on how to handle the error. A checked exception doesn’t make the full decision for the calling function, but it does eliminate ignoring the error as an option from the calling function.\n\nJava also supports unchecked exceptions which do not need to be explicitly caught. For example, NumberFormatException or NullPointerException are unchecked exceptions. If an unchecked exception is thrown and not caught, it bubbles up through the call stack until some piece of code does catch it. If no code catches it, it results in a fatal error and terminates the execution of the JVM. The RuntimeException class and any of its subclasses are unchecked exceptions.\n\nIn our ComplexRootException example above, because we extended RuntimeException we made it an unchecked exception, allowing the calling function to decide not only how to handle it, but whether or not to handle it at all. If we had instead decided to extend Exception we would have made our exception a checked exception.\n\nThere is considerable debate as to whether or not checked exceptions are a good thing (and as to whether or not unchecked exceptions are a good thing)."