In Java, why not just use "throws Exception"?

Question

In the Java development environment, I've seen examples where people include e.g. "throws java.io.IOException" to a method, and they've also said that you can separate each exception declared in the "throws" with a comma, such as "throws java.io.IOException, ArrayOutOfBoundsException ...".

However, since both of these are subclasses of java.lang.Exception, why not just write "throws Exception"? Why waste such time writing down the specific exception types?

Answer 1

Someone upthumbed the wrong answer and down-thumbed a good one.



Bob is right, but there is more to it than readability. When you put "throws Exception" on a method used by other classes, you force every calling method to catch or throw Exception too. In practice, this means a try/catch around just the call to your method. Every single one of them. You force your callers to use more code simply because you didn't want to list the checked exceptions you throw or didn't plan to catch from the methods you call.



If every method does that, then calling code becomes either unreliable (by not properly handling checked exceptions) or unwieldy.



None of this matters much in main(), which is only called by the JVM, or in private methods which aren't even visible outside the class. You might lose a few reputation points among Java developers that have to look at your code later, but that's about it.



Still, it's a good idea to write even throw-away code in the style that you plan to deliver in a professional setting. Habits formed during this kind of practice are the ones you're likely to revert to under deadline pressure later.



Edit: I read your comments to David's answer, and can add that the idea of "checked exceptions" is part of Java, but not C# and not in other languages I can think of right away. It's not everyone's favorite, and there's some discussion of problems and why C# doesn't have it here:

http://www.artima.com/intv/handcuffs.html



Coming from C#, you might like Anders Hejlsberg's view reported there, but read on. There are two sided to the coin.



Java does give the class designer a choice. Exceptions derived from RuntimeException are not checked and not subject to "throws" or mandatory "catch" requirements. As a class user, though, you need to handle any checked exceptions from the Java API classes or any third party classes you use. More about that from a Java point of view here:

http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html



I tend to avoid creating checked exceptions for some of the reasons that Hejlsberg mentions, unless the exception is a part of the API being created. (A constructor can't return status and must create an object, so exceptions are the primary way for a constructor to say that something went wrong.) When I do use them (or a forced to by a class that I use), I do try to use them properly.



Hope some of that helps...

Answer 2

Because sometimes you want to handle particular exceptions differently. If you wanted to handle IOException one way, ArrayOutOfBoundsException a different way, and any other exception a third way, you'd have to specify those first two specifically (or multiple with a comma) and use the final "Exception" to catch anything that wasn't already caught from the previous exceptions.



You can just catch "Exception" if you are going to handle all exceptions in the exact same manner, and the error handler code doesn't care which exception was thrown.

Answer 3

For much the same reason that we don't call every variable i, j and k ;-)



Experience has shown that the more effort we put into writing code that is readable and expressive, then the less effort we'll have to expend debugging it. After a while, it becomes second nature to write expressive code that we do it even for trivial programs.