Why do I have to give an identifier?

Question

In code:

try
{
    System.out.print(fromClient.readLine());
}
catch(IOException )//LINE 1
{
     System.err.println("Error while trying to read from Client");
}

In code line marked as LINE 1 compiler forces me to give an identifier even though I'm not using it. Why this unnatural constrain? And then if I type an identifier I'm getting warning that identifier isn't used. It just doesn't make sense to me, forcing a programmer to do something unnecesarry and surplus. And after me someone will revise this code and will be wondering if I didn't use this variable on purpouse or I just forgot. So in order to avoid that I have to write additional comment explaining why I do not use variable which is unnecessary in my code.
Thanks

Answer 1

The identifier name is required to make parsing simpler for the compiler. And omitting the exception in a catch clause is considered bad practice IMHO rarely a good idea - in production code you should (almost always) print / log it and/or rethrow it. So not using the identifier name should be the exception (no pun intended) rather than the rule.

But if you really have a good reason to omit not use it, you can add a comment to explain your point, [Update2] and/or to tell your IDE to suppress that kind of inspection for that specific code block (most IDEs allow this) [/Update2].

Update: OK, "bad practice" may be too strong a word :-) Let me try to explain my point better.

What I mean is that typically when you catch an exception, it is preferred to try to log / use as much information out of it as you can. Which implies that you actually refer to the exception variable.

In your example above, if you only log "Error while trying to read from Client", that is a very limited amount of information. The actual cause of the problem might be (just a few guesses) a corrupted file, a network error, a formatting error ... Logging the data within the IOException would provide much more detail about it, making the problem easier to fix.

Answer 2

In your catch, you are defining the variable that is caught, not just the exception's class. It's similar to IOException ex = new IOException() semantically. And you should actually be using the variable. See all the rational in Is it okay that I sometimes sink my exceptions here on SO. Logging the exception, as you are doing, provides some information. Ideally, though, your code should handle the exception in some way, even if it is just to report the error to the client (which, if your app is a console app, it would to be doing).

If you have catch(IOException ex), you can also get the full stack trace with ex.printStackTrace(), use localized messages, and more. It's good for debugging. Try it!

You can get more information in the Exceptions tutorial.

As an interesting note, in Java 7 the syntax for catching exceptions is expected to change slightly, as multicatch and final rethrow were excepted.

Answer 3

The compiler is correct in calling you on this. According to the Java grammar, the "parameter" to a catch clause must have both a type and a variable identifier. If it is omitted, your program text is no longer a syntactically correct Java program.

CatchClause: catch ( FormalParameter ) Block

FormalParameter: [final] Type VariableDeclaratorId

As for why things are this way - I think it's easier to parse, and allowing an option here doesn't provide you with anything. It is very common to react to an error by making use of the exception object, so the typical case is to have a variable, not to omit it. Since there is no added performance cost, they probably just went with allowing you to not use it. In my experience no IDE warns you about an unused variable if you don't refer to the exception object within your catch block.

Answer 4

Simplifying the other answers - I think - when you catch an exception, you need to actually catch something, and you're specifying what that's going to be. It's not "execute this code if something goes wrong", it's "execute this code if this particular thing goes wrong".

Best practice is to log or rethrow; if you're catching an exception that's not something you want to log or rethrow, did you really need to catch it, or could you have done it another way?