| The Java programming language comes with many exceptions built into the language. These cover many different types of common, unfortunate situations. For example, ArrayIndex-OutOfBoundsException is popular. It is thrown to indicate that you have attempted to access an index that does not exist in an array. The system will throw this exception if you have an array of 4 elements, and you type x = myArray[100] (no 100th element). Or if you type x = myArray[-1] (cannot be negative value). Or if you type x = myArray[4] (there are only elements 0-3 in a four element array). This is a good example of the kind of thing that can happen easily, but from which it also should be easy to recover. UncheckedExceptions The ArrayIndexOutOfBoundsException is not something that the compiler will force you to plan for when you are writing your application. If you write some code that works with an array, the assumption on the part of the language designers is that you will be careful enough about what you are doing that you should not need to write a complete try/catch block every time you access an array. If you do get an ArrayIndexOutOfBoundsException , it is almost certainly because you have some poorly written code in there that needs permanent fixing. Because the compiler doesn't check if you are handling the possible occurrence of this kind of exception, it is called an unchecked exception. It means that you can compile the following code:
int x = myArray[i]; //look, mano try catch statement !
NullPointerException is another unchecked exception that you run into during development. Try typing the following:
Object obj = null; obj.toString();
You can't call the dot operator on null . Your program blows up. The language designers know that you know this, and they don't want you having to clutter your code with tons of handling statements. So, NullPointerException is unchecked. If you try to divide integers by zero, the virtual machine will generate an ArithmeticException . Again, you are trusted not to do this, and therefore spared the red tape and inconvenience of planning for it. You are not required to handle any exception that is a RuntimeException , or one of its subclasses. CheckedExceptions Checked exceptions, on the other hand, must be dealt with. The compiler checks to see that you have at least something that looks like it will handle exceptions any time you invoke an operation that could generate a checked exception. An IOException , a MalformedURLException , and a SQLException are all good examples of checked exceptions. You cannot compile a class that contains this code on its own:
File f = new File("s"); f.getCanonicalFile();
If you try to compile the preceding code, your compiler complains that you have an unhandled exception lurking in there. Something inside that code block declares that it throws an exception of type IOException , and so you need to deal with it. The following will fix it:
public void someMethod () { File f = new File("s"); try { f.getCanonicalFile(); } catch (IOException ioe) { //do something here } }
The getCanonicalFile() method of the File class might throw an IOException because it is possible that the call would require reading the file system. The creation of the new File object does not need to be wrapped inside the try/catch block because it just creates an object of type File ”it doesn't actually do anything on the file system. So, what you're doing is no more potentially problematic than the following:
String s = "well, hello Mr. Fancy Pants";
The compiler cannot judge the quality of your plans to handle the potential IOException . In fact, your catch block can be empty ”you can write no code at all between the curly braces. But you have been forced to acknowledge a potential danger. | 