Why not use exceptions to control the flow of execution? This works in most cases, but makes code fragile. Here is an example.
String s;
try {
s = doSomething();
}
catch(SomeException se) {
s = doSomethingElse();
}
There is nothing wrong with this code as long as the method doSomething() throws exceptions of class SomeException or one of its subclasses.
Let’s say, you modified the implementation of doSomething() to throw some runtime exception. The above try/catch would fail to catch this. Checked exceptions may not solve this problem either. For example, the following code will compile even when you add a new checked exception for the doSomething() method.
private String getSomething() throws Exception
{
String s;
try {
s = doSomething();
}
catch(SomeException se) {
s = doSomethingElse();
}
}
This is because of the throws clause. This code is obviously carelessly written. But it is not uncommon to come across such code in complex software that took years to harden.
The point is that, using exceptions to control the flow of execution is a bad idea. It works in the short-term, but compromises resilience.
On a related note, it would be great if IDEs get smart enough to point such mistakes.
{ 6 comments… read them below or add one }
PMD has a rule which checks for this – ExceptionAsFlowControl:
http://pmd.sourceforge.net/rules/strictexception.html
[Reply]
How does this make the code fragile? There are times when you need to do this.
If doSomething fails, you need to record that it happened.
In your mind, are you supposed to catch exceptions, then ignore them? That is much much worse.
[Reply]
This is a reply to the comment “How does this make the code fragile? There are times when you need to do this”.
There are better ways to control the flow of execution without using exceptions. A simple “if/else” could be used to make such choices. Exceptions are for exceptions, and the catch block is for recovering from exceptions, but not to make algorithmic choices. When such choices are make via exceptions, code could become fragile.
[Reply]
Throwing an exception is an expensive operation in java compared to a break, continue or return. In the situation you give as an example, it’s actually an appropriate behaviour, assuming that the method defines SomeException in the interface.
In the situation where it’s a run time exception, you catch the exception and then throw it again:
[code]
private String getSomething() throws SomeException
{
String s;
try {
s = doSomething();
}
catch(SomeException se) {
s = doSomethingElse();
throw se;
}
}[/code]
So that your special error handling behaviour goes through. Maybe there should be a fillInStackTrace() in there, I forget.
[Reply]
I think you meant to say “‘throws Exception’ is a bad idea”.
Surely.
[Reply]
This is reply to “you meant to say, “throws Exception’ is a bad idea”.
Yes, I Believe, there are a lot of ways, where one can use conditions to control the flow. And throwing exceptions to control the flow in a program is really a bad idea.
[Reply]