First Program In Java

If you are a beginner in java and still looking for a help to write your first java program, you can go through this blog and than definitely you will become able to write your first program in java

Basics for Beginners in java.

If you are the new for java then you must learn the concept given below. First go through the following example and than you will be able to understand the basic logic the JAVA program .

First program in java..

Class A

{

public static void main(String arg[])

{

System.out.println("java is a very interesting language");

}

}

Logic behind the public method in JAVA

The public keyword is an access specifier, which allows the programmer to control

the visibility of class members. When a class member is preceded by public, then that member may be accessed by code outside the class in which it is declared. (The opposite

of public is private, which prevents a member from being used by code defined outside of its class.) In this case, main( ) must be declared as public, since it must be called by code outside of its class when the program is started.

Logic behind the static keyword in the above code.

The keyword static allows main( ) to be called without having to instantiate a particular instance of the class. This is necessary since main( ) is called by the Java interpreter before any objects are made.

Logic behind the void keyword in the above code.

The keyword void simply tells the compiler that main( ) does not return a value.

Logic behind the void keyword in the above code.

In JAVA , main( ) is the method called when a Java application begins. Be careful that Java is case-sensitive. Thus, Main is different from main. It is important to understand that the Java compiler will compile classes that do not contain a main( ) method. But the Java interpreter has no way to run these classes. So, if you had typed Main instead of main, the compiler would still compile your program. However, the Java interpreter would report an error because it would be unable to find the main( ) method.

Logic behind the String arg[] in the above code.

In main( ), there is only one parameter. String args[ ] declares a parameter named args, which is an array of instances of the class String. (Arrays are collections of similar objects.) Objects of type String store character strings. In this case, args receives any command-line arguments present when the program is executed.

Logic behind the System.out in the above code.

System is a class.

Out is a static object.

Println() is the method of PrintStream class.

System.out refers to the standard output stream.

Access modifiers in JAVA

In JAVA access specifiers are public, private, protected and default. Java also defines a

default access level. protected applies only when inheritance is involved , and by default any class will be public within the package . The other access specifiers are described next.
Let’s begin by defining public and private. When a member of a class is modified
by the public specifier, then that member can be accessed by any other code. When a
member of a class is specified as private, then that member can only be accessed by
other members of its class.
When no access specifier is used, then by default the
member of a class is public within its own package, but cannot be accessed outside of
its package.

DATA STRUCTURE IN JAVA

Collections in Java

• Arrays

Has special language support

• Iterators

Iterator (i)

• Collections (also called containers)

Collection (i)

Set (i)

HashSet (c), TreeSet (c)

List (i),

ArrayList (c), LinkedList (c)

Map (i),

HashMap (c), TreeMap (c)

Array

• Most efficient way to hold references to objects.

• Advantages

An array know the type it holds, i.e., compile-time type checking.

An array know its size, i.e., ask for the length.

An array can hold primitive types directly.

• Disadvantages

An array can only hold one type of objects (including primitives).

Arrays are fixed size.

Array, Example

• Helper class java.util.Arrays

Search and sort: binarySearch(), sort()

Comparison: equals() (many overloaded)

Instantiation: fill() (many overloaded)

Conversion: asList()

class Car{}; // minimal dummy class

Car[] cars1; // null reference

Car[] cars2 = new Car[10]; // null references

for (int i = 0; i <>

cars2[i] = new Car();

// Aggregated initialization

Car[] cars3 = {new Car(), new Car(), new Car(), new Car()};

cars1 = {new Car(), new Car(), new Car()};

Overview of Collection

• A collection is a group of data manipulate as a single object.

Corresponds to a bag.

• Insulate client programs from the implementation.

array, linked list, hash table, balanced binary tree

• Like C++'s Standard Template Library (STL)

• Can grow as necessary.

• Contain only Objects (reference types).

• Heterogeneous.

• Can be made thread safe (concurrent access).

• Can be made not-modifiable.

Collection Interfaces

• Collections are primarily defined through a set of interfaces.

Supported by a set of classes that implement the interfaces

• Interfaces are used of flexibility reasons

Programs that uses an interface is not tightened to a specific

implementation of a collection.

It is easy to change or replace the underlying collection class with

another (more efficient) class that implements the same interface.

Collection Interfaces and Classes

The Iterator Interface

• The idea: Select each element in a collection

Hide the underlying collection

Iterator

hasNext()

-( it's return type is Boolean).

next()

( it will check for next element)

remove()

Collection

isEmpty()

add()

remove()

...

list

• Iterators are fail-fast

Exception thrown if collection is modified externally, i.e., not via the

iterator (multi-threading).

The Iterator Interface, cont.

// an example

public static void main (String[] args){

ArrayList cars = new ArrayList();

for (int i = 0; i <>

cars.add (new Car());

Iterator it = cars.iterator();

while (it.hasNext())

System.out.println ((Car)it.next());

}

// the interface definition

Interface Iterator {

boolean hasNext();

Object next(); // note "one-way" traffic

void remove();

}

The Collection Interface

public interface Collection {

// Basic Operations

int size();

boolean isEmpty();

boolean contains(Object element);

boolean add(Object element); // Optional

boolean remove(Object element); // Optional

Iterator iterator();

// Bulk Operations

boolean containsAll(Collection c);

boolean addAll(Collection c); // Optional

boolean removeAll(Collection c); // Optional

boolean retainAll(Collection c); // Optional

void clear(); // Optional

// Array Operations

Object[] toArray();

Object[] toArray(Object a[]);

}

The Set Interface

• Corresponds to the mathematical definition of a set (no

duplicates are allowed).

• Compared to the Collection interface

Interface is identical.

Every constructor must create a collection without duplicates.

The operation add cannot add an element already in the set.

The method call set1.equals(set2) works at follows

set1 ??set2, and set2 ??set1

Set Idioms

• set1 ??set2

set1.addAll(set2)

• set1 ??set2

set1.retainAll(set2)

• set1 ??set2

set1.removeAll(set2)

HashSet and TreeSet Classes

• HashSet and TreeSet implement the interface Set.

• HashSet

Implemented using a hash table.

No ordering of elements.

add, remove, and contains methods constant time complexity

O(c).

• TreeSet

Implemented using a tree structure.

Guarantees ordering of elements.

add, remove, and contains methods logarithmic time complexity

O(log (n)), where n is the number of elements in the set.

HashSet, Example

import java.util.*;

public class FindDups {

public static void main(String args[]){

Set s = new HashSet();

for (int i = 0; i <>

if (!s.add(args[i]))

System.out.println("Duplicate detected: " +

args[i]);

}

System.out.println(s.size() +

" distinct words detected: " +

s);

}

}

The List Interface

• The List interface corresponds to an order group of elements.

Duplicates are allowed.

• Extensions compared to the Collection interface

Access to elements via indexes, like arrays

add (int, Object), get(int), remove(int),

set(int, Object) (note set = replace bad name for the method)

Search for elements

indexOf(Object), lastIndexOf(Object)

Specialized Iterator, call ListIterator

Extraction of sublist

subList(int fromIndex, int toIndex)

The List Interface, cont.

Further requirements compared to the Collection Interface

• add(Object)adds at the end of the list.

• remove(Object)removes at the start of the list.

• list1.equals(list2)the ordering of the elements is

taken into consideration.

• Extra requirements to the method hashCode.

list1.equals(list2) implies that

list1.hashCode()==list2.hashCode()

The List Interface, cont.

public interface List extends Collection {

// Positional Access

Object get(int index);

Object set(int index, Object element); // Optional

void add(int index, Object element); // Optional

Object remove(int index); // Optional

abstract boolean addAll(int index, Collection c);

// Optional

// Search

int indexOf(Object o);

int lastIndexOf(Object o);

// Iteration

ListIterator listIterator();

ListIterator listIterator(int index);

// Range-view

List subList(int from, int to);

}

ArrayList and LinkedList Classes

• The classes ArrayList and LinkedList implement the

List interface.

• ArrayList is an array based implementation where elements

can be accessed directly via the get and set methods.

Default choice for simple sequence.

• LinkedList is based on a double linked list

Gives better performance on add and remove compared to

ArrayList.

Gives poorer performance on get and set methods compared to

ArrayList.

ArrayList, Example

// [Source: java.sun.com]

import java.util.*;

public class Shuffle {

public static void main(String args[]) {

List l = new ArrayList();

for (int i = 0; i <>

l.add(args[i]);

Collections.shuffle(l, new Random());

System.out.println(l);

}

}

LinkedList, Example

import java.util.*;

public class MyStack {

private LinkedList list = new LinkedList();

public void push(Object o){

list.addFirst(o);

}

public Object top(){

return list.getFirst();

}

public Object pop(){

return list.removeFirst();

}

public static void main(String args[]) {

Car myCar;

MyStack s = new MyStack();

s.push (new Car());

myCar = (Car)s.pop();

}

}

The ListIterator Interface

public interface ListIterator extends Iterator {

boolean hasNext();

Object next();

boolean hasPrevious();

Object previous();

int nextIndex();

int previousIndex();

void remove(); // Optional

void set(Object o); // Optional

void add(Object o); // Optional

}

The Map Interface

• A Map is an object that maps keys to values. Also called an

associative array or a dictionary.

• Methods for adding and deleting

put(Object key, Object value)

remove (Object key)

• Methods for extraction objects

get (Object key)

• Methods to retrieve the keys, the values, and (key, value) pairs

keySet() // returns a Set

values() // returns a Collection,

entrySet() // returns a set

The MAP Interface, cont.

public interface Map {

// Basic Operations

Object put(Object key, Object value);

Object get(Object key);

Object remove(Object key);

boolean containsKey(Object key);

boolean containsValue(Object value);

int size();

boolean isEmpty();

// Bulk Operations

void putAll(Map t);

void clear();

// Collection Views

public Set keySet();

public Collection values();

public Set entrySet();

// Interface for entrySet elements

public interface Entry {

Object getKey();

Object getValue();

Object setValue(Object value);

}

}

HashMap and TreeMap Classes

• The HashMap and HashTree classes implement the Map

interface.

• HashMap

The implementation is based on a hash table.

No ordering on (key, value) pairs.

• TreeMap

The implementation is based on red-black tree structure.

(key, value) pairs are ordered on the key.

HashMap, Example

import java.util.*;

public class Freq {

private static final Integer ONE = new Integer(1);

public static void main(String args[]) {

Map m = new HashMap();

// Initialize frequency table from command line

for (int i=0; i <>

Integer freq = (Integer) m.get(args[i]);

m.put(args[i], (freq==null ? ONE :

new Integer(freq.intValue() + 1)));

}

System.out.println(m.size()+

" distinct words detected:");

System.out.println(m);

}

}

Static Methods on Collections

• Collection

Search and sort: binarySearch(), sort()

Reorganization: reverse(), shuffle()

Wrappings: unModifiableCollection,

synchonizedCollection

Collection Advantages and Disadvantages

Advantages

• Can hold different types of

objects.

• Resizable

Disadvantages

• Must cast to correct type

• Cannot do compile-time type

checking.

Summary

• Array

Holds objects of known type.

Fixed size.

• Collections

Generalization of the array concept.

Set of interfaces defined in Java for storing object.

Multiple types of objects.

Resizable.

• Queue, Stack, Deque classes absent

Use LinkedList.

About inheritance in java.

Inheritance in java – is the inclusion of behavior (i.e. methods) and state (i.e. variables) of a base class in a derived class so
that they are accessible in that derived class. The key benefit of Inheritance is that it provides the formal mechanism for
code reuse. Any shared piece of business logic can be moved from the derived class into the base class as part of
refactoring process to improve maintainability of your code by avoiding code duplication. The existing class is called the
superclass and the derived class is called the subclass. Inheritance can also be defined as the process whereby one
object acquires characteristics from one or more other objects the same way children acquire characteristics from their
parents. There are two types of inheritances:

1. Implementation inheritance (aka class inheritance): You can extend an application’s functionality by reusing
functionality in the parent class by inheriting all or some of the operations already implemented. In Java, you can only
inherit from one superclass. Implementation inheritance promotes reusability but improper use of class inheritance can
cause programming nightmares by breaking encapsulation and making future changes a problem. With implementation
inheritance, the subclass becomes tightly coupled with the superclass. This will make the design fragile because if you
want to change the superclass, you must know all the details of the subclasses to avoid breaking them. So when using
implementation inheritance, make sure that the subclasses depend only on the behavior of the superclass, not on
the actual implementation. For example in the above diagram, the subclasses should only be concerned about the
behavior known as area() but not how it is implemented.

2. Interface inheritance (aka type inheritance): This is also known as subtyping. Interfaces provide a mechanism for
specifying a relationship between otherwise unrelated classes, typically by specifying a set of common methods each
implementing class must contain. Interface inheritance promotes the design concept of program to interfaces not to
implementations. This also reduces the coupling or implementation dependencies between systems. In Java, you can
implement any number of interfaces. This is more flexible than implementation inheritance because it won’t lock you into
specific implementations which make subclasses difficult to maintain. So care should be taken not to break the
implementing classes by modifying the interfaces.
Which one to use? Prefer interface inheritance to implementation inheritance because it promotes the design concept of
coding to an interface and reduces coupling. Interface inheritance can achieve code reuse with the help of object
composition. If you look at Gang of Four (GoF) design patterns, you can see that it favors interface inheritance to
implementation inheritance.

Polymorphism in java.

Polymorphism in java – means the ability of a single variable of a given type to be used to reference objects of
different types, and automatically call the method that is specific to the type of object the variable references. In a
nutshell, polymorphism is a bottom-up method call. The benefit of polymorphism is that it is very easy to add new
classes of derived objects without breaking the calling code (i.e. getTotArea() in the sample code shown
below) that uses the polymorphic classes or interfaces. When you send a message to an object even though you
don’t know what specific type it is, and the right thing happens, that’s called polymorphism. The process used by
object-oriented programming languages to implement polymorphism is called dynamic binding.

DEALING WITH EXCEPTIONS IN JAVA

JAVA EXCEPTIONS
In JAVA, chances are that your program quit and spewed a bunch of mysterious errors to the screen. Those mysterious errors are exceptions. When your program quits, it's because an exception was "thrown." Exceptions can be thrown by the system or thrown by you, and they can be caught as well (catching an exception involves dealing with it so your program doesn't crash. You'll learn more about this later). "An exception was thrown" is the proper JAVA terminology for "an error happened."
Exceptions don't occur, they are thrown. JAVA throws an exception in response to an unusual situation. You can also throw your own exceptions, or catch an exception to gracefully manage errors.
In JAVA an Exception can be defined as "An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions".
The heart of the JAVA exception system is the exception itself. Exceptions in JAVA are actual objects, instances of classes that inherit from the class Throwable. When an exception is thrown, an instance of a Throwable class is created.

Throwable has two subclasses: Error and Exception. Instances of Error are internal errors in the JAVA runtime environment (the virtual machine). These errors are rare and usually fatal; there's not much you can do about them (either to catch them or to throw them yourself), but they exist so that JAVA can use them if it needs to.
The class Exception is more interesting. Subclasses of Exception fall into two general groups:
· Runtime exceptions (subclasses of the class RuntimeException) such as ArrayIndexOutofBounds, SecurityException, or NullPointerException.
· Other exceptions such as EOFException and MalformedURLException.
Runtime exceptions usually occur because of code that isn't very robust. An ArrayIndexOutofBounds exception, for example, should never be thrown if you're properly checking to make sure your code doesn't extend past the end of an array. NullPointerException exceptions won't happen if you don't try to reference the values of a variable that doesn't actually hold an object. If your program is causing runtime exceptions under any circumstances whatsoever, you should be fixing those problems before you even begin to deal with exception management.
The final group of exceptions is the most interesting because these are the exceptions that indicate that something very strange and out of control is happening. EOFExceptions, for example, happen when you're reading from a file and the file ends before you expect it to. MalformedURLExceptions happen when a URL isn't in the right format (perhaps your user typed it wrong). This group includes exceptions that you yourself create to signal unusual cases that may occur in your own programs.
Exceptions are arranged in a hierarchy like other classes, where the Exception superclasses are more general errors, and subclasses are more specific errors. This organization will become more important to you as you deal with exceptions in your own code.
Most of the exception classes are part of the java.lang package (including Throwable, Exception, and RuntimeException). But many of the other packages define other exceptions, and those exceptions are used throughout the class library. For example, the java.io package defines a general exception class called IOException, which is subclassed not only in the java.io package for input and output exceptions (EOFException, FileNotFoundException), but also in the java.net classes for networking exceptions such as MalFormedURLException.

Managing Exceptions In JAVA.
In many cases, the JAVA compiler enforces exception management when you try to use methods that use exceptions; you'll need to deal with those exceptions in your own code or it simply won't compile. In this section you'll learn about that consistency checking and how to use the try, catch, and finally language keywords to deal with exceptions that may or may not occur.
The JAVA compiler enforces exception management when you try to use methods that use exceptions; you'll need to deal with those exceptions in your own code or it simply won't compile. In this section you'll learn about that consistency checking and how to use the try, catch, and finally language keywords to deal with exceptions that may or may not occur.
Exception Consistency Checking
The more you work with the JAVA class libraries, the more likely it is that you'll run into a compiler error (an exception!) similar to this one:
TestProg.java
Exception java.lang.InterruptedException
must be caught or it must be declared in the throws clause
of this method.
What on earth does that mean? In JAVA, a method can indicate the kinds of errors it might possibly throw. For example, methods that read from files might potentially throw IOException errors, so those methods are declared with a special modifier that indicates potential errors. When you use those methods in your own JAVA programs, you have to protect your code against those exceptions. This rule is enforced by the compiler itself, the same way that the compiler checks to make sure that you're using methods with the right number of arguments and that all your variable types match the thing you're assigning to them.
Why is this check in place? By having methods declare the exceptions they throw, and by forcing you to handle those exceptions in some way, the potential for fatal errors in a program occurring because you simply didn't know they could occur is minimized. You no longer have to carefully read the documentation or the code of an object you're going to use to make sure you've dealt with all the potential problems-JAVA does the checking for you. And, on the other side, if you define your methods so that they indicate the exceptions they can throw, then JAVA can tell users of your objects to handle those errors.
Protecting Code and Catching Exceptions
Let's assume that you've been happily coding and during a test compile you ran into that exception message. According to the message, you have to either catch the error or declare that your method throws it. Let's deal with the first case: catching potential exceptions.
To catch an exception, you do two things:
· You protect the code that contains the method that might throw an exception inside a try block.
· You test for and deal with an exception inside a catch block.
What try and catch effectively mean is "try this bit of code that might cause an exception. If it executes okay, go on with the program. If it doesn't, catch the exception and deal with it."
For Example :
try { Thread.sleep(1000) }
catch (InterruptedException e) {}
While this example uses try and catch, it's not a very good use of it. Here, the Thread.sleep() class method could potentially throw an exception of type InterruptedException (for when the thread is interrupted from running). So we've put the call to sleep() inside the try clause to catch that exception if it happens. And inside catch (inside the parentheses), we indicate that we're specifically looking for InterruptedException exceptions. The problem here is that there isn't anything inside the catch clause-in other words, we'll catch the exception if it happens, but then we'll drop it on the floor and pretend we didn't see it. In all but the simplest cases (such as this one, where the exception really doesn't matter), you're going to want to put something inside the braces after catch to try to do something responsible to clean up after the exception happens.
The part of the catch clause inside the parentheses is similar to the parameter list of a method definition; it contains the class of the exception to be caught and a variable name (e is very commonly used). Inside the body of the catch clause, you can then refer to the exception object, for example, to get to the detailed error message contained in the getMessage() method:
catch (InterruptedException e) {
System.out.println("Ooops. Error: " + e.getMessage());
}
Here's another example. Say you have a program that reads from a file. This program most likely uses one of the streams classes . Stream and I/O," but the basic idea here is that you open a connection to a file and then use the read() method to get data from it. What if some strange disk error happens and the read() method can't read anything? What if the file is truncated and has fewer bytes in it than you expected? In either of these instances, the read() method will throw an IOException which, if you didn't catch it, would cause your program to stop executing and possibly crash. By putting your read() method inside a try clause, you can then deal gracefully with that error inside catch to clean up after the error and return to some safe state, to patch things up enough to be able to proceed, or, if all else fails, to save as much of the current program's state as possible and to exit. This example does just that; it tries to read from the file, and catches exceptions if they happen:
try {
while (numbytes <= mybuffer.length) {
myinputstream.read(mybuffer);
numbytes;++
}
} catch (IOException e) {
System.out.println("Ooops, IO Exception. Only read " + numbytes.");
// other cleanup code
}
Here, the "other cleanup code" can be anything you want it to be; perhaps you can go on with the program using the partial information you got from the file, or perhaps you want to put up a dialog saying that the file is corrupt and to let the user try to select another file or do some other operation.
Note that because the Exception classes are organized into hierarchies as other classes are, and because of the rule that you can use a subclass anywhere a superclass is expected, you can catch "groups" of exceptions and handle them with the same catch code. For example, although there are several different types of IOExceptions (EOFException, FileNotFoundException, and so on-see the java.io package for examples), by catching IOException you also catch instances of any subclass of IOException.
What if you do want to catch very different kinds of exceptions that aren't related by inheritance? You can use multiple catch clauses for a given try, like this:
try {
// protected code
} catch (OneKindOfException e) {
...
} catch (AnotherKindOfException e2) {
....
} catch (YetAnotherException e3) {
...
} catch (StilMoreException e4) {
....
}
Note that because the scope of local variables inside catch is the same as the scope of the outer block (the method definition or a loop if you're inside one), you'll have to use different local variables for each individual catch.
Because the first catch clause that matches is executed, you can build chains such as the following:
try {
someReallyExceptionalMethod();
} catch (NullPointerException n) { // a subclass of RuntimeException
. . .
} catch (RuntimeException r) { // a subclass of Exception
. . .
} catch (IOException i) { // a subclass of Exception
. . .
} catch (MyFirstException m) { // our subclass of Exception
. . .
} catch (Exception e) { // a subclass of Throwable
. . .
} catch (Throwable t) {
. . . // Errors, plus anything not caught above are caught here
}
By listing subclasses before their parent classes, the parent catches anything it would normally catch that's also not one of the subclasses above it. By juggling chains like these, you can express almost any combination of tests.
The finally Clause
Suppose there is some action in your code that you absolutely must do, no matter what happens, whether an exception is thrown or not. Usually, this is to free some external resource after acquiring it, to close a file after opening it, or something similar. While you could put that action both inside a catch and outside it, that would be duplicating the same code in two different places. Instead, put one copy of that code inside a special optional part of the try...catch clause, called finally:
SomeFileClass f = new SomeFileClass();
if (f.open("/a/file/name/path")) {
try {
someReallyExceptionalMethod();
{ catch (IOException e) {
// deal with errors
} finally {
f.close();
}
}
The finally clause is actually useful outside exceptions; you can also use it to execute cleanup code after a return, a break, or a continue inside loops. For the latter cases, you can use a try clause with a finally but without a catch clause.
Here's a fairly complex example of how this might work:
int mysteriousState = getContext();
while (true) {
System.out.print("Who ");
try {
System.out.print("is ");
if (mysteriousState == 1)
return;
System.out.print("that ");
if (mysteriousState == 2)
break;
System.out.print("strange ");
if (mysteriousState == 3)
continue;
System.out.print("but kindly ");
if (mysteriousState == 4)
throw new UncaughtException();
System.out.print("not at all ");
} finally {
System.out.print("amusing man?\n");
}
System.out.print("I'd like to meet the man");
}
System.out.print("Please tell me.\n");
Here is the output produced depending on the value of mysteriousState:
1 Who is amusing man? Please tell me.
2 Who is that amusing man? Please tell me.
3 Who is that strange amusing man? Who is that strange ....
4 Who is that strange but kindly amusing man? Please tell me.
5 Who is that strange but kindly not at all amusing man?
I'd like to meet that man. Who is that strange ...
Note
In cases 3 and 5, the output never ends until you quit the program. In 4, an error message generated by the UncaughtException is also printed.
Declaring Methods That Might Throw Exceptions
In the previous example you learned how to deal with methods that might possibly throw exceptions by protecting code and catching any exceptions that occur. The JAVA compiler will check to make sure you've somehow dealt with a method's exceptions-but how did it know which exceptions to tell you about in the first place?
The answer is that the original method indicated in its signature the exceptions that it might possibly throw. You can use this mechanism in your own methods-in fact, it's good style to do so to make sure that other users of your classes are alerted to the errors your methods may come across.
To indicate that a method may possibly throw an exception, you use a special clause in the method definition called throws.
The throws Clause
To indicate that some code in the body of your method may throw an exception, simply add the throws keyword after the signature for the method (before the opening brace) with the name or names of the exception that your method throws:
public boolean myMethod (int x, int y) throws AnException {
...
}
If your method may possibly throw multiple kinds of exceptions, you can put all of them in the throws clause, separated by commas:
public boolean myOtherMethod (int x, int y)
throws AnException, AnotherExeption, AThirdException {
...
}
Note that as with catch you can use a superclass of a group of exceptions to indicate that your method may throw any subclass of that exception:
public void YetAnotherMethod() throws IOException {
...
}
Keep in mind that adding a throws method to your method definition simply means that the method might throw an exception if something goes wrong, not that it actually will. The throws clause simply provides extra information to your method definition about potential exceptions and allows JAVA to make sure that your method is being used correctly by other people.
Think of a method's overall description as a contract between the designer of that method (or class) and the caller of the method (you can be either side of that contract, of course). Usually, the description indicates the types of a method's arguments, what it returns, and the general semantics of what it normally does. Using throws, you add information about the abnormal things it can do as well. This new part of the contract helps to separate and make explicit all the places where exceptional conditions should be handled in your program, and that makes large-scale design easier.
Which Exceptions Should You Throw?
Once you decide to declare that your method might throw an exception, you have to decide which exceptions it might throw (and actually throw them or call a method that will throw them-you'll learn about throwing your own exceptions in the next section). In many instances, this will be apparent from the operation of the method itself. Perhaps you're creating and throwing your own exceptions, in which case you'll know exactly which exceptions to throw.
You don't really have to list all the possible exceptions that your method could throw; some exceptions are handled by the runtime itself and are so common (well, not common, but ubiquitous) that you don't have to deal with them. In particular, exceptions of either class Error or RuntimeException (or any of their subclasses) do not have to be listed in your throws clause. They get special treatment because they can occur anywhere within a JAVA program and are usually conditions that you, as the programmer, did not directly cause. One good example is OutOfMemoryError, which can happen anywhere, at any time, and for any number of reasons. These two kinds of exceptions are called implicit exceptions, and you don't have to worry about them.
Implicit exceptions are exceptions that are subclasses of the classes RuntimeException and Error. Implicit exceptions are usually thrown by the JAVA runtime itself. You do not have to declare that your method throws them.
Note
You can, of course, choose to list these errors and runtime exceptions in your throws clause if you like, but the callers of your methods will not be forced to handle them; only non-runtime exceptions must be handled.
All other exceptions are called explicit exceptions and are potential candidates of a throws clause in your method.
Passing On Exceptions
In addition to declaring methods that throw exceptions, there's one other instance in which your method definition may include a throws clause. In this case, you want to use a method that throws an exception, but you don't want to catch that exception or deal with it. In many cases, it might make more sense for the method that calls your method to deal with that exception rather than for you to deal with it. There's nothing wrong with this; it's a fairly common occurrence that you won't actually deal with an exception, but will pass it back to the method that calls yours. At any rate, it's a better idea to pass on exceptions to calling methods than to catch them and ignore them.
Rather than using the try and catch clauses in the body of your method, you can declare your method with a throws clause such that it, too, might possibly throw the appropriate exception. Then it's the responsibility of the method that calls your method to deal with that exception. This is the other case that will satisfy the JAVA compiler that you have done something with a given method. Here's another way of implementing an example that reads characters from a stream:
public void readTheFile(String filename) throws IO Exception {
// open the file, init the stream, etc.
while (numbytes <= mybuffer.length) {
myinputstream.read(mybuffer);
numbytes;++
}
This example is similar to the example used previously today; remember that the read() method was declared to throw an IOException, so you had to use try and catch to use it. Once you declare your method to throw an exception, however, you can use other methods that also throw those exceptions inside the body of this method, without needing to protect the code or catch the exception.
Note
You can, of course, deal with other exceptions using try and catch in the body of your method in addition to passing on the exceptions you listed in the throws clause. You can also both deal with the exception in some way and then re-throw it so that your method's calling method has to deal with it anyhow. You'll learn how to throw methods in the next section.
throws and Inheritance
If your method definition overrides a method in a superclass that includes a throws clause, there are special rules for how your overridden method deals with throws. Unlike with the other parts of the method signature, your new method does not have to have the same set of exceptions listed in the throws clause. Because there's a potential that your new method may deal better with exceptions, rather than just throwing them, your subclass's method can potentially throw fewer types of exceptions than its superclass's method definition, up to and including throwing no exceptions at all. That means that you can have the following two class definitions and things will work just fine:
public class Fruit {
public void ripen() throws RotException {
...
}
}
public class WaxFruit extends Fruit {
public void ripen() {
...
}
}
The converse of this rule is not true; a subclass's method cannot throw more exceptions (either exceptions of different types or more general exception classes) than its superclass's method.