Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows

AspAutocadCDot netExcelFox proHtmlJava
LinuxMathcadPhotoshopPhpSqlVisual studioWindowsXml

Standard Java exceptions: The special case of RuntimeException


+ Font mai mare | - Font mai mic


Trimite pe Messenger
Initializing the base class
Name hiding
Windowing Components And Layout Classes
Returning an array
Creating new data types: class
You must create all the objects
Date And Advanced Classes
Toolkit, Window, Container, And Events
Coding style
Overloading on return values

Standard Java exceptions

Java contains a class called Throwable that describes anything that can be thrown as an exception. There are two general types of Throwable objects (ďtypes ofĒ = ďinherited fromĒ). Error represents compile-time and system errors that you donít worry about catching (except in special cases). Exception is the basic type that can be thrown from any of the standard Java library class methods and from your methods and run-time accidents.

The best way to get an overview of the exceptions is to browse online Java documentation from (Of course, itís easier to download it first.) Itís worth doing this once just to get a feel for the various exceptions, but youíll soon see that there isnít anything special between one exception and the next except for the name. Also, the number of exceptions in Java keeps expanding; basically itís pointless to print them in a book. Any new library you get from a third-party vendor will probably have its own exceptions as well. The important thing to understand is the concept and what you should do with the exceptions.


This is the basic exception class your program can catch. Other exceptions are derived from this. The basic idea is that the name of the exception represents the problem that occurred and the exception name is intended to be relatively self-explanatory. The exceptions are not all defined in java.lang; some are created to support other libraries such as util, net, and io, which you can see from their full class names or what they are inherited from. For example, all IO exceptions are inherited from

The special case of RuntimeException

The first example in this chapter was

if(t == null)
throw new NullPointerException();

It can be a bit horrifying to think that you must check for null on every handle that is passed into a method (since you canít know if the caller has passed you a valid handle). Fortunately, you donít Ė this is part of the standard run-time checking that Java performs for you, and if any call is made to a null handle, Java will automatically throw a NullPointerException. So the above bit of code is always superfluous.

Thereís a whole group of exception types that are in this category. Theyíre always thrown automatically by Java and you donít need to include them in your exception specifications. Conveniently enough, theyíre all grouped together by putting them under a single base class called RuntimeException, which is a perfect example of inheritance: it establishes a family of types that have some characteristics and behaviors in common. Also, you never need to write an exception specification saying that a method might throw a RuntimeException, since thatís just assumed. Because they indicate bugs, you virtually never catch a RuntimeException Ė itís dealt with automatically. If you were forced to check for RuntimeExceptions your code could get messy. Even though you donít typically catch RuntimeExceptions, in your own packages you might choose to throw some of the RuntimeExceptions.

What happens when you donít catch such exceptions? Since the compiler doesnít enforce exception specifications for these, itís quite plausible that a RuntimeException could percolate all the way out to your main( ) method without being caught. To see what happens in this case, try the following example:


// Ignoring RuntimeExceptions

public class NeverCaught

static void g()

public static void main(String[] args)

} ///:~

You can already see that a RuntimeException (or anything inherited from it) is a special case, since the compiler doesnít require an exception specification for these types.

The output is:

java.lang.RuntimeException: From f()

at NeverCaught.f(

at NeverCaught.g(

at NeverCaught.main(

So the answer is: If a RuntimeException gets all the way out to main( ) without being caught, printStackTrace( ) is called for that exception as the program exits.

Keep in mind that itís possible to ignore only RuntimeExceptions in your coding, since all other handling is carefully enforced by the compiler. The reasoning is that a RuntimeException represents a programming error:

An error you cannot catch (receiving a null handle handed to your method by a client programmer, for example)

An error that you, as a programmer, should have checked for in your code (such as ArrayIndexOutOfBoundsException where you should have paid attention to the size of the array).

You can see what a tremendous benefit it is to have exceptions in this case, since they help in the debugging process.

Itís interesting to notice that you cannot classify Java exception handling as a single-purpose tool. Yes, it is designed to handle those pesky run-time errors that will occur because of forces outside your codeís control, but itís also essential for certain types of programming bugs that the compiler cannot detect.

Politica de confidentialitate



Vizualizari: 555
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2022 . All rights reserved

Distribuie URL

Adauga cod HTML in site