Is "throws Throwable" good practice

Question

In the past I'd read tons of code with methods like:

public Object doSomething() throws Throwable {     ... } 

Is it common practice to do that?

What are pros & cons?

throws Trowable seemed to me like the "Agent Orange" way of getting the Exception- matter done

EDIT

---

1. Handle expected Exceptions in the Method

2. Throw unexpected Exceptions (one by one)

3. Don't care of Errors

Is that the way to go?

Answer 1

You should not throw Throwable. Here's why.

Throwable is the top of the hierarchy of things that can be thrown and is made up of Exceptions and Errors. Since Errors by definition arise from unsalvagable conditions, it is pointless to include them in your method declaration. That leaves just Exception.

You should declare your method with throws Exception instead.

Note that the narrower the range of throws the better.

Declaring your method to be throws Exception is ok if your method doesn't generate the exceptions, but instead calls other code that is declared as throws Exception and you want exceptions to percolate up the call stack.

If your method is the generating the exception, then declare a narrower range, eg throws IOException, MyProcessingException, etc

Answer 2

That's a loaded question. This isn't so much about exception handling as it is about code readability.

It depends where you get your code samples from. Professionals prefer to be more specific when throwing out of a method. The main reason is that it keeps your APIs more readable. For example, if your method throws Throwable, that basically means anything could happen and your method doesn't want to deal with it, no matter what. But really, only a limited number of things could happen:

• Whatever checked exceptions resulting from other calls you are making in your method
• Whatever checked exceptions you are throwing on purpose based on your own assertions
• Whatever unchecked exception you didn't plan for
• Errors (java.lang.Error) that are more global to the JVM and the environment

By specifically stating the exceptions you want to throw, you are telling the users of your API about what they should beware of. For example, when you use InputStream, you'll notice most methods throw at least java.io.IOException, which gives you some useful information about what you should watch for.

When coding, as a general rule, you want to try to keep your APIs as expressive as possible. You've got essentially one line of code to show the public API of a method (i.e. its signature, annotations too I guess), so you want it completely expressive (return type, name, parameters, but also the thrown exceptions).

As far as catching the throwables and printing the stack trace, I'd say that you should not catch the exception unless you can do something about it. Instead, let it roll up the call stack until some class catches it to do something about it. Sometimes, it may roll all the way up to your main class, which I guess would have to catch it and print the stack trace as last resort. Basically, if you can't act upon the exception, then let it go up the call stack. Also it is extremely rare that you find yourself in a situation where you should silence an exception (i.e. catch it but do nothing about it). That's usually inviting problems when comes time to troubleshoot issues.

Here is a fun but interesting article around misuse of exception handling in general.