Java divides exceptions into two categories:

1. General exceptions
2. Run-time exceptions

The general exceptions (also called checked exceptions) must be handled. That is, a try-catch must either be nested around the call to the method that throws the exception or the method signature must include a throws clause for this exception. (Then other methods that invoke this method must then catch the exception or throw it up the line.) The compiler will throw an error message if it detects an uncaught exception and will not compile the file.

The run-time exceptions do not have to be caught. This avoids requiring that a try-catch be place around, for example, every integer division operation to catch a divide by zero or around every array variable to watch for indices going out of bounds.

However, you should handle possible run-time exceptions if you think there is a reasonable chance of one occurring. In the above string parsing example, the NumberFormatException extends (we discuss subclassing in Chapter 4) RuntimeException so it is optional to catch this error.


If a Java program attempts to carry out an illegal operation, it does not necessarily halt processing at that point. In most cases, the JVM provides for the possiblity of catching the problem and recovering from it. To emphasize that such problems are not fatal, the term exception is used rather than error.

For example, what if by accident we put a non-numeric string into an applet tag parameter and it is passed to the wrapper method Integer.parseInt() as shown below:
class myApplet extends Applet
{
....
init ()
{
String int_string = getParameter ("intNumber");
// If the parameter returned is not a
// numeric string, there will be a problem:
int data =
Integer.parseInt (int_string);
aMethod (data);
}
}

In this case, a Java run-time exception would be generated and the applet would halt.


for more visit source site as given bellow:

http://www.particle.kth. se/~lindsey/JavaCourse/Book/Part1/J ava/Chapter03/exceptions.html

Answered by Om Prakash , an ibibo Master, at 7:10 PM on September 25, 2008

the Java language does not require methods to catch or specify runtime exceptions, it's tempting for programmers to write code that throws only runtime exceptions or to make all of their exception subclasses inherit from RuntimeException. Both of these programming shortcuts allow programmers to write Java code without bothering with all of the nagging errors from the compiler and without bothering to specify or catch any exceptions. While this may seem convenient to the programmer, it sidesteps the intent of Java's catch or specify requirement and can cause problems for the programmers using your classes.

InputFile.java:8: Warning: Exception
java.io.FileNotFoundExce ption must be caught, or it must be
declared in throws clause of this method.
fis = new FileInputStream(filename);
^

Why did the Java designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Because any exception that can be thrown by a method is really part of the method's public programming interface: callers of a method must know about the exceptions that a method can throw in order to intelligently and conciously decide what to do about those exceptions. The exceptions that a method can throw are as much a part of that method's programming interface as its parameters and return value.

Your next question might be: "Well then, if it's so good to document a method's API including the exceptions that it can throw, why not specify runtime exceptions, too?"

Runtime exceptions represent problems that are detected by the runtime system. This includes arithmetic exceptions (such as when dividing by zero), pointer exceptions (such as trying to access an object through a null reference), and indexing exceptions (such as attempting to access an array element through an index that is too large or too small).

Runtime exceptions can occur anywhere in a program and in a typical program can be very numerous. Typically, the cost of checking for runtime exceptions exceeds the benefit of catching or specifying them. Thus the compiler does not require that you catch or specify runtime exceptions, although you can.

Checked exceptions represent useful information about the operation of a legally specified request that the caller may have had no control over and that the caller needs to be informed about--for example, the file system is now full, or the remote end has closed the connection, or the access privileges don't allow this action.

What does it buy you if you throw a RuntimeException or create a subclass of RuntimeException just because you don't want to deal with specifying it? Simply, you get the ability to throw an exception without specifying that you do so. In other words, it is a way to avoid documenting the exceptions that a method can throw. When is this good? Well, when is it ever good to avoid documenting a method's behavior? The answer is "hardly ever."

Answered by Sharad Singh , an ibibo Master, at 5:53 PM on September 25, 2008

1: NullPointerException :
Thrown when an application attempts to use null in a case where an object is required. These include:

* Calling the instance method of a null object.
* Accessing or modifying the field of a null object.
* Taking the length of null as if it were an array.
* Accessing or modifying the slots of null as if it were an array.
* Throwing null as if it were a Throwable value.

2: IllegalStateException :
Signals that a method has been invoked at an illegal or inappropriate time. In other words, the Java environment or Java application is not in an appropriate state for the requested operation.

3: NoSuchElementException :
Thrown by the nextElement method of an Enumeration to indicate that there are no more elements in the enumeration.

4:SystemException:
The root class for all CORBA standard exceptions. These exceptions may be thrown as a result of any CORBA operation invocation and may also be returned by many standard CORBA API methods. The standard exceptions contain a minor code, allowing more detailed specification, and a completion status. This class is subclassed to generate each one of the set of standard ORB exceptions. SystemException extends java.lang.RuntimeException; thus none of the SystemException exceptions need to be declared in signatures of the Java methods mapped from operations in IDL interfaces.

5:NegativeArraySizeException :
Thrown if an application tries to create an array with negative size.

Answered by Ashish Yadav , an ibibo Wizard, at 5:43 PM on September 25, 2008

well sunil,
An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions.

Because the Java language does not require methods to catch or specify runtime exceptions, it's tempting for programmers to write code that throws only runtime exceptions or to make all of their exception subclasses inherit from RuntimeException. Both of these programming shortcuts allow programmers to write Java code without bothering with all of the nagging errors from the compiler and without bothering to specify or catch any exceptions. While this may seem convenient to the programmer, it sidesteps the intent of Java's catch or specify requirement and can cause problems for the programmers using your classes.
InputFile.java:8: Warning: Exception
java.io.FileNotFoundExce ption must be caught, or it must be
declared in throws clause of this method.
fis = new FileInputStream(filename);
^

Answered by Venkata , an ibibo Specialist, at 3:41 PM on September 25, 2008

Java provides various built in classes to the programmer which facilitates coding in Java. The most common exceptions are subclasses of the standard type RuntimeException. They are not requirewd to be manually included in any method’s throws list.

They are basically defined as unchecked exceptions because they are not checked by the complier to see if a method handles or throws these exceptions.


A small list of these Unchecked Run Time Built in exceptions is mentioned below for your reference:

Exceptions Meaning

ArithmeticException Arithmeti c error, such as divide-by-zero.

ArrayIndexOutOfB oundsException Array index is out-of-bounds.

ArrayStoreExcepti on Assignment to an array element of an incompatible type.

ClassCastException Inval id cast.

IllegalArgumentException Illegal argument used to invoke a method.

IllegalMonitorStateExcep tion Illegal monitor operation, such as waiting on an unlocked thread.

IllegalStateException Environment or application is in incorrect state.

IllegalThreadStateExcepti on Requested operation not compatible with current thread state.

IndexOutOfBoundsException Some type of index is out-of-bounds.

NegativeArraySize Exception Array created with a negative size.

NullPointerException Invalid use of a null reference.

NumberFormatException Invalid conversion of a string to a numeric Format

SecurityException Attempt to violate security.

StringIndexOutOfBounds Attempt to index outside the bounds of a string

UnsupportedOperationExcep tion An unsupported operation was encountered

Answered by Hem@nt .... , an ibibo Master, at 12:24 PM on September 25, 2008

Consider the following example:

class TestException extends Exception {
TestException() { super(); }
TestException(String s) { super(s); }
}
class Test {
public static void main(String[] args) {
for (String arg :args) {
try {
thrower(arg);
System.out.println("Test \"" + arg +
"\" didn't throw an exception");
} catch (Exception e) {
System.out.println("Test \"" + arg +
"\" threw a " + e.getClass() +
"\n with message: " + e.getMessage());
}
}
}
static int thrower(String s) throws TestException {
try {
if (s.equals("divide")) {
int i = 0;
return i/i;
}
if (s.equals("null")) {
s = null;
return s.length();
}
if (s.equals("test"))
throw new TestException("Test message");
return 0;
} finally {
System.out.println("[throwe r(\"" + s +
"\") done]");
}
}
}

If we execute the test program, passing it the arguments:

divide null not test

it produces the output:

[thrower("divide") done]
Test "divide" threw a class java.lang.ArithmeticException
with message: / by zero
[thrower("null") done]
Test "null" threw a class java.lang.NullPointerException
with message: null
[thrower("not") done]
Test "not" didn't throw an exception
[thrower("test") done]
Test "test" threw a class TestException
with message: Test message

This example declares an exception class TestException. The main method of class Test invokes the thrower method four times, causing exceptions to be thrown three of the four times. The try statement in method main catches each exception that the thrower throws. Whether the invocation of thrower completes normally or abruptly, a message is printed describing what happened.

The declaration of the method thrower must have a throws clause because it can throw instances of TestException, which is a checked exception class (§11.2). A compile-time error would occur if the throws clause were omitted.
11.5.1 Loading and Linkage Errors
The Java virtual machine throws an object that is an instance of a subclass of LinkageError when a loading, linkage, preparation, verification or initialization error occurs:

* The loading process is described in §12.2.
* The linking process is described in §12.3.
* The class verification process is described in §12.3.1.
* The class preparation process is described in §12.3.2.
* The class initialization process is described in §12.4.

11.5.2 Virtual Machine Errors
The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes. The Java API defines a number of exception classes, both checked and unchecked. Additional exception classes, both checked and unchecked, may be declared by programmers. See §11.5 for a description of the exception class hierarchy and some of the exception classes defined by the Java API and Java virtual machin.
Before a class is initialized, its superclasses are initialized, if they have not previously been initialized.

Thus, the test program:

class Super {
static { System.out.print("Super "); }
}
class One {
static { System.out.print("One "); }
}
class Two extends Super {
static { System.out.print("Two "); }
}
class Test {
public static void main(String[] args) {
One o = null;<

Answered by shaista , an ibibo Master, at 9:47 AM on September 25, 2008

well, Java exception handling is used to handle error conditions in a program systematically by taking the necessary action. Exception handlers can be written to catch a specific exception such as Number Format exception, or an entire group of exceptions by using a generic exception handlers. Any exceptions not specifically handled within a Java program are caught by the Java run time environment

An exception is a subclass of the Exception/Error class, both of which are subclasses of the Throwable class. Java exceptions are raised with the throw keyword and handled within a catch block.

A Program Showing How the JVM throws an Exception at runtime

public class DivideException {

public static void main(String[] args) {
division(100,4); // Line 1
division(100,0); // Line 2
System.out.println("Exit main().");
}

public static void division(int totalSum, int totalNumber) {
System.out.println("Computing Division.");
int average = totalSum/totalNumber;
System.out.println("Average : "+ average);
}
}


Source: http://www.javabeginner.com/ja va-exceptions.htm

Answered by Romi , an ibibo Master, at 9:27 AM on September 25, 2008

Well Sunil, Because the Java language does not require methods to catch or specify runtime exceptions, it's tempting for programmers to write code that throws only runtime exceptions or to make all of their exception subclasses inherit from RuntimeException. Both of these programming shortcuts allow programmers to write Java code without bothering with all of the nagging errors from the compiler and without bothering to specify or catch any exceptions. While this may seem convenient to the programmer, it sidesteps the intent of Java's catch or specify requirement and can cause problems for the programmers using your classes.

InputFile.java:8: Warning: Exception
java.io.FileNotFoundException must be caught, or it must be
declared in throws clause of this method.
fis = new FileInputStream(filename);
^

Why did the Java designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Because any exception that can be thrown by a method is really part of the method's public programming interface: callers of a method must know about the exceptions that a method can throw in order to intelligently and conciously decide what to do about those exceptions. The exceptions that a method can throw are as much a part of that method's programming interface as its parameters and return value.

Your next question might be: "Well then, if it's so good to document a method's API including the exceptions that it can throw, why not specify runtime exceptions, too?"

Runtime exceptions represent problems that are detected by the runtime system. This includes arithmetic exceptions (such as when dividing by zero), pointer exceptions (such as trying to access an object through a null reference), and indexing exceptions (such as attempting to access an array element through an index that is too large or too small).

Runtime exceptions can occur anywhere in a program and in a typical program can be very numerous. Typically, the cost of checking for runtime exceptions exceeds the benefit of catching or specifying them. Thus the compiler does not require that you catch or specify runtime exceptions, although you can.

Checked exceptions represent useful information about the operation of a legally specified request that the caller may have had no control over and that the caller needs to be informed about--for example, the file system is now full, or the remote end has closed the connection, or the access privileges don't allow this action.

What does it buy you if you throw a RuntimeException or create a subclass of RuntimeException just because you don't want to deal with specifying it? Simply, you get the ability to throw an exception without specifying that you do so. In other words, it is a way to avoid documenting the exceptions that a method can throw. When is this good? Well, when is it ever good to avoid documenting a method's behavior? The answer is "hardly ever."

Rules of Thumb:

* A method can detect and throw a RuntimeException when it's encountered an error in the virtual machine runtime. However, it's typically easier to just let the virtual machine detect and throw it. Normally, the methods you write should throw Exceptions, not RuntimeException.
* Similarly, you create a subclass of RuntimeException when you are creating an error in the virtual machine runtime (which you probably aren't). Otherwise you should subclass Exception.
* Do not throw a runtime exception or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.

For more details , Please visit the source site :

http://journals.ecs.soton .ac.uk/java/tutorial/java/exce ptions/runtime.html

Answered by Alok Gupta , an ibibo Guru, at 9:27 AM on September 25, 2008

well, RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.

A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

Since:
JDK1.0
See Also:
Serialized Form

Constructor Summary
RuntimeException()
Constructs a new runtime exception with null as its detail message.
RuntimeException(Str ing message)
Constructs a new runtime exception with the specified detail message.
RuntimeException(Str ing message, Throwable cause)
Constructs a new runtime exception with the specified detail message and cause.
RuntimeException(Throw able cause)
Constructs a new runtime exception with the specified cause and a detail message of (cause==null ? null : cause.toString()) (which typically contains the class and detail message of cause).

For more: http://java.sun.com/j2se/1.5.0 /docs/api/java/lang/RuntimeExc eption.html

Answered by Satya ~ , an ibibo Master, at 9:16 AM on September 25, 2008