tags:

views:

767

answers:

3

Is there any possibility of exceptions to occur other than RuntimeException in Java? Thanks.

+4  A: 

The java.lang package defines the following standard exception classes that are not runtime exceptions:

  • ClassNotFoundException: This exception is thrown to indicate that a class that is to be loaded cannot be found.

  • CloneNotSupportedException: This exception is thrown when the clone() method has been called for an object that does not implement the Cloneable interface and thus cannot be cloned.

  • Exception: The appropriate subclass of this exception is thrown in response to an error detected at the virtual machine level. If a program defines its own exception classes, they should be subclasses of the Exception class.

  • IllegalAccessException: This exception is thrown when a program tries to dynamically load a class (i.e., uses the forName() method of the Class class, or the findSystemClass() or the loadClass() method of the ClassLoader class) and the currently executing method does not have access to the specified class because it is in another package and not public. This exception is also thrown when a program tries to create an instance of a class (i.e., uses the newInstance() method of the Class class) that does not have a zero-argument constructor accessible to the caller.

  • InstantiationException: This exception is thrown in response to an attempt to instantiate an abstract class or an interface using the newInstance() method of the Class class.

  • InterruptedException: This exception is thrown to signal that a thread that is sleeping, waiting, or otherwise paused has been interrupted by another thread.

  • NoSuchFieldException: This exception is thrown when a specified variable cannot be found. This exception is new in Java 1.1.

  • NoSuchMethodException: This exception is thrown when a specified method cannot be found.

Warrior
+2  A: 

Basically in java (opposed to .NET) you have two types of exceptions:

  • Checked Exception: All classes that inherit from exception. Client code has to handle this kind of exceptions (enforced in the compiler) via try-catch or throws clause.
  • Unchecked Exception: All classes that inherit from RuntimeException. Client code does not have to handle this type of exceptions.

May I suggest the following O'Reilly On Java Exception article.

Igor Zelaya
They're three not two. See my answer.
OscarRyz
Java and Spec# have checked exceptions and can in some form run on .NET.
Tom Hawtin - tackline
Come on compadre! Error is a type of run time exception since it does not need to be caught in the throws clause. Read the On Java Article.
Igor Zelaya
You're wrong in both senses. Error is a type of Throwable, because that's what it extends. Furthermore, since Error is not meant to be caught, it is also not of type RuntimeException, because some RuntimeExceptions (i.e. NumberFormatException) are meant to be caught and handled sometimes.
MetroidFan2002
@Igor: je je .. I didn't meant exceptions as in class hierarchy but as concept as a whole. Saludos compa!
OscarRyz
+10  A: 

Yes, there are Three kinds.

Checked exceptions

The compiler will let you know when they can possible be thrown, due to a failure in the environment most likely.

They should be caught, if the program can do something with it, otherwise it is preferred to let them go.

Most of them inherit from

java.lang.Exception

or from

java.lang.Throwable

Although it is better to inherit from the former.

For example:

java.io.IOException

Signals that an I/O exception of some sort has occurred. This class is the general class of exceptions produced by failed or interrupted I/O operations.

Errors

These are special kinds of exceptions. They SHOULD NOT BE CAUGHT for when they occur means that something really really bad just happened.

All of them inherit from

java.lang.Error

For example:

java.lang.OutOfMemoryError

Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.

or

java.lang.StackOverflowError

Thrown when a stack overflow occurs because an application recurses too deeply.

RuntimeExceptions

Used to identify programmer failures, rather than resource failures.

A Runtime exception could "normally" be avoided while coding. If you have one most likely you're doing something wrong.

Sometimes runtime exceptions are caught, but, unless you know exactly what you're doing and why, catching them is a bad practice ( again, unless that's exactly what you need )

They inherit from

java.lang.RuntimeException

For example

java.lang.ArrayIndexOutOfBoundsException

Thrown to indicate that an array has been accessed with an illegal index. The index is either negative or greater than or equal to the size of the array

or

java.lang.NullPointerException

Thrown when an application attempts to use null in a case where an object is required

About the last two, MOST of the times, they can be avoided by programming carefully and understand what the state of the program is ( does this array have 5 elements? why should I try to access -1 or 6th. Is this reference null? why should I call null.toString() )

Although I have had arguments with guys that claim that all NPE should be caught. Well what can I say.

OscarRyz
This is the best answer here, except the past sense of "catch" is "caught", not "catched".
MetroidFan2002
@MetroidFan2002: Syntax exception catched I mean caught :) ( I should've take seriously to Google check spelling red underline )
OscarRyz
@mmyers: That's because they were worst ;) I could have waited for your edit and have "catched/caught" fixed in the process. For some reason I'm ashame to explain, it took me 15 minutes and a machine restart to make that correction. Error code: PEBKAC
OscarRyz