In Java, is using throws Exception instead of throwing multiple specific exceptions good practice?

Here's the problem with throwing specific exceptions... Suppose someone extends your class and wants to override your method. Suppose their new implementation needs to throw a different type of exception. (How would you ever be able to predict what exceptions an overriding method might need to throw?) The person writing the overriding method only has two choices: 1) handle the exception himself (likely a bad choice), or 2) wrap the real exception in one of the allowed exception types and re-throw.

But option 2 has two problems. First, when you dump your exceptions to your log files, you'll get long ugly chains of nested exceptions. More importantly, you'll lose your ability to catch specific exceptions. For example, suppose the overriding method calls another method that talks to the database and throws a DeadlockException if the resulting SQL caused a deadlock. The overriding method has to catch this exception, wrap it in one of the allowed types, and rethrow. This makes it impossible for code further up the stack to catch and detect the DeadlockException.

Your question ultimately gets into the heart of the debate about checked versus unchecked exceptions. You can Google and find lots of arguments for both sides of the debate. I think that ultimately, if you believe in checked exceptions, you should be very explicit about what exceptions a method throws. If you don't like checked exceptions, you should declare every method to throw Exception. I fall in the latter camp.

By the way, for people who don't like checked exceptions, I don't like the idea of using RuntimeException's everywhere. The problem is that you'll likely need to incorporate a 3rd party library that uses Exception's rather than RuntimeException's. Then, your code will have to catch all Exception's from the library and wrap them in RuntimeException's. That creates a mess.

So, if I were starting a Java project from scratch again, I'd just declare every

You need to distinguish between generic code and more specific code.

Consider the return types of functions as an analogy. If you're writing a class like "ArrayList", you want it to be very general, so the parameters and return values are often generic "Object"s. But when you're writing code more specific to your application, like a "getRetiredEmployees" function, it would be a very bad idea to return Object. You more likely want to return Employee[] or something of that sort.

So sure, a framework like Spring is going to expect generic Exceptions because it doesn't have any idea what exceptions your particular application is going to throw. There's no way the authors of Spring could know that you were going to throw an "EmployeeNotInSpecifiedDepartment" exception or whatever. How could they? But if you're writing the sendPensionChecks function and you call getRetiredEmployees, you can reasonably expect to know specific exceptions that that function might throw, and what you should do to handle them.

Clint Miller brings up a valid point about not knowing how a class might be extended. I concede this is a problem with making your exceptions specific. But going from there to "just make everything a generic Exception" is giving up too easily. It's like saying that because someone someday might extend our getRetiredEmployees function to in some cases return EmployeeSpouse's along with Employee's, that therefore we should just give up and make the return type Object. If this is code you are using internally and you control, it's a non-problem: If you need to add a new Exception to a function, then add it. If this is an API that you are publishing to the world, then yes, the problem is much trickier. I'd say the general solution is to try to think out rationally what exceptions make sense and include them all, even if they aren't all presently implemented. If one of your clients is doing something completely unanticipated, oh well, that's a probl

List every exception. This way:
* It is clearly define what CAN go wrong.
* Users of your class can know EXACTLY what exceptions they should handle.

Also, an overriding method should do THE SAME THING as the overridden, but in a different manner. Hence, how could you have another exception, which IS NOT a subclass of an already thrown exception? You shouldn't. Besides, you SHOULD NOT throw new exceptions in a subclass, since a subclass is supposed to be able to replace it's parent class, hence if it gets passed on as "p" to

public void method(Parent p);

How would "method" know it has to handle some new exception? It shouldn't need to. And it means improper design (either of the parent class, or the subclass).