For example, many methods in frameworks/JDK might throw
java.lang.SecurityException
but this is not indicated in the method signature (since that is a practice normally reserved for checked exceptions). I want to argue that declaring RuntimeExceptions in method sigs has many benefits (akin to static type checking for example). Am I drunk or otherwise?
I would not declare an unchecked exception in the signature, since it is misleading to the user of that API. It is no longer obvious whether the exception has to be explicitly handled.
Declaring it in the javadoc is a better approach since it allows someone to handle it if they think it is necessary, but knowing they can ignore it if they want. This makes the separation between checked and unchecked clear.
From the Oracle Java tutorial:
"If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as 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 one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program's clarity.
Take a look at the javadoc for Collection#add
There's a whole slew of unchecked exceptions mentioned:
Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.
If you have the patience, I'd recommend thoroughly documenting the possible exceptions thrown by your methods this way. In a way, it's even more important to do this for unchecked exceptions, as checked exceptions are somewhat self-documenting (the compiler forces the calling code to acknowledge them).
In my point of view it's better to declare runtime exceptions at least in the javadoc for the method. Declaring it in the signature makes it even more obvious what may happen when something goes wrong. This is my main reason for suggesting to provide this information.
FYI: as time has progressed (now in 2017) I am leaning now far more to documenting them in javadoc only and avoiding checked exceptions as much as possible.
In my view unchecked exceptions should never be declared in the method signature as that is contrary to their nature.
If, however, a method is likely to throw some unchecked exceptions noting the likely circumstances in @throws in Javadoc can be helpful for others invoking the method in understanding what can go wrong. This is only useful though for exceptions that the callers is likely to be able to handle (such as a NPE due to bad input etc.)
If you are writing an api for use by others, then there is ample reason for explicit documentation of your intent in the api and there is no downside to declaring RuntimeExceptions in the method signature.
This has to do with the discussion regarding checked exceptions. Most would agree that exceptions shouldn't be declared in methods signatures.
There is also a discussion regarding how runtime exceptions should be used. I agree with one poster that runtime exceptions should denote a programming error or a fatal condition. So there isn't much merit declaring them in the signature. Every method could potentially through one.
