Question

We all know it is needed.

But WHY is it needed in Java alone, when other similar languages that have exception handling capablities don’t require us to write “throws Exception”? Is there anyone who knows what was happening when Java language was designed and why they made it that way? Just curious.

P.S. This may not be a practical or really necessary question – it might not help me in anyway with my ongoing projects. But certain language features kindle my curiosity 😀

Edit
Looks like my question was very vague! I think I worded the question wrongly. We need to use the “throws Exception” kind of syntax at some points during programming when dealing with Java code. But something like that is never needed in C# or C++ or even VB.Net and PHP. So why Java alone insists on this?

Answer 1

As other answers here have pointed out, the throws clause is only required for checked exceptions, which is a feature that currently only exists in Java.

The official answer as to why Java has checked exceptions is well documented:

Why did the designers decide to force
a method to specify all uncaught
checked exceptions that can be thrown
within its scope? Any Exception that
can be thrown by a method is part of
the method’s public programming
interface. Those who call a method
must know about the exceptions that a
method can throw so that they can
decide what to do about them. These
exceptions are as much a part of that
method’s programming interface as its
parameters and return value.

However, this decision is highly controversial, even within the Java community:

Recently, several well-regarded
experts, including Bruce Eckel and Rod
Johnson, have publicly stated that
while they initially agreed completely
with the orthodox position on checked
exceptions, they’ve concluded that
exclusive use of checked exceptions is
not as good an idea as it appeared at
first, and that checked exceptions
have become a significant source of
problems for many large projects.
Eckel takes a more extreme view,
suggesting that all exceptions should
be unchecked; Johnson’s view is more
conservative, but still suggests that
the orthodox preference for checked
exceptions is excessive. (It’s worth
noting that the architects of C#, who
almost certainly had plenty of
experience using Java technology,
chose to omit checked exceptions from
the language design, making all
exceptions unchecked exceptions. They
did, however, leave room for an
implementation of checked exceptions
at a later time.)

Personally, I find checked exceptions to be useful only when your API makes a habit of catching all exceptions and re-throwing them as something appropriate to your abstraction layer. For example, an in-memory object cache that happens to use a disk or SQL backend to cache data should never throw IOException or SQLException — instead, it should throw (and declare) some user-defined exception like CacheFailureException or similar.

Also, you might find Ned Batchelder’s article Exceptions in the Rainforest illuminating in regard to this question.