Some argue that @throws should not be used at all.
Instead, one may simply rely on the javadoc tool to automatically document all exceptions placed in the throws clause.
However, others disagree.

Checked Exceptions :

declaring only checked exceptions in the method's throws clause is a widely followed convention

javadoc automatically generates basic documentation for all exceptions in the throws clause

the documentation is generated with no extra effort on your part

Unchecked Exceptions :

aren't typically placed in the method's throws clause.

are very rarely caught by the caller.

do not form part of the contract of the method,
but rather represent what happens when the contract is broken. The caller cannot recover from such errors.

almost always occur when a precondition on a parameter is not met. However, such conditions are
almost always already documented in a @param tag.

Therefore, if you :

only place checked exceptions in the throws clause

don't use @throws at all

then only checked exceptions will appear in javadoc.
It can be argued that this is beneficial: since checked exceptions are more important than unchecked ones,
it's best that they stand out in javadoc, without being mixed in with other exceptions of minor interest.

In almost all cases, a @throws tag simply repeats verbatim conditions already stated
in a @param tag, and doesn't add in any way to the specification
of the method's behavior. Such repetition should be regarded with grave suspicion.
When a change occurs, it's far too easy to forget to update the javadoc in two separate places.

A general comment regarding broken contracts can be stated once in the
javadoc overview.html document :
"If the requirements or promises of any method's contract are not fulfilled
(that is, if there is a bug in either the method or its caller), then an
unchecked exception will be thrown. The precise type of such an unchecked
exception does not form part of any method's contract."

Example

BasketBall has two constructors.

The first constructor includes several @throws tags in its
javadoc. However, aside from the type of the unchecked exception, all of
these @throws tags are logically equivalent to some previous statement
in a @param tag. They add nothing to the contract.

The second constructor follows a different style. It has a single parameter,
and the conditions on this parameter are stated once (and once only) in
its @param tag.