Special case of RuntimeException

The first example in this chapter is:
if (t = = null)
throw new NullPointerException ();
It would seem pretty scary to have to check for NULL in every handle that passes into a method (because it is not known whether the caller has passed a valid handle). But luckily, we don't have to do this-it's part of the standard runtime check that Java does. If a call is made to an empty handle, Java automatically generates a nullpointerexception violation. So the above code is superfluous in any case.
This category contains a series of offending types. They are all automatically generated by Java and need not be included in our own offending code. Most conveniently, they are all grouped together by placing them under a single base class named RuntimeException. This is a good example of inheritance: it establishes a series of types that have some commonality, all of which have some common characteristics and behaviors. In addition, we do not need to write a specific code of practice, pointing out that a method may "throw" a runtimeexception because it has been assumed that such a situation might arise. Because they are used to indicate errors in programming, it is almost never necessary to specifically capture a "run-time violation"--runtimeexception--It is automatically processed by default. If we have to check runtimeexception, our code becomes quite complicated. In our own bag, we can choose to "throw" a part of the runtimeexception.
What happens if these violations are not captured? Since the compiler does not force the offending specification to capture them, a runtimeexception may filter out all the ways we reach the main () method if not captured. To realize what's happening at this point, try this example:
 

//: Nevercaught.java//ignoring runtimeexceptions public class Nevercaught {static void F () {
  throw new RuntimeException ("From F ()");
  static void G () {f ();
  public static void Main (string[] args) {g (); }
} ///:~

As you have seen, a runtimeexception (or anything inherited from it) is a special case because the compiler does not require that the offending specification be specified for these types.
The output is as follows:

Java.lang.RuntimeException:From F ()
At Nevercaught.f (nevercaught.java:9)
At NEVERCAUGHT.G (nevercaught.java:12)
At Nevercaught.main (nevercaught.java:15)

So the answer is: If a runtimeexception gets all the way to main () and is not caught, then when the program exits, it calls Printstacktrace () for that violation.
Note that you may be able to ignore only runtimeexception in your own code, because the compiler has properly implemented all other controls. Because RuntimeException represents a programming error at this time:
(1) An error that we cannot capture (for example, a null handle passed by a client programmer to its own method).
(2) as a programmer, a bug that should be checked in its own code (such as Arrayindexoutofboundexception, should pay attention to the size of the array at this point).
As you can see, the best way to do this is to do so in this case, because they help debug the program.
Another interesting point is that we cannot classify Java violations as a single purpose tool. Indeed, they are designed to control annoying run-time errors-generated by other forces outside the scope of code control. However, it is also particularly helpful in debugging certain special types of programming errors that are not detected by the compiler.