throw in a finally

[Anony!]

Just been playing with RefactorIT

Found the Audit tool and ran it.

It alerted me to something that I never considered to be a problem.

It graded high priority - throwing clauses in a finally block.

Why do they see this as a problem? How bad is it?

It is unusual to have a throw statement in a finally block. I believe there
are other ways of achieving the same semantics by changing the structure of
your code.

My Joshua Bloch Bible doesn't say anything about it.

I can see that alerting the situation is good, but High Priority?

Well it is high priority because the exception has to be caught.

So how do you typically avoid throws in a finally?

have throws statements in each catch block, but this is not recommended.

And any how, if the method is declared as throws....
Then the finally block can throw it anyway.

Correct, but there must also be an exception handler to catch the thrown
exception, and that could be the problem your experiencing.

HTH
AAA

 

[Liz]

It is unusual to have a throw statement in a finally block. I believe there
are other ways of achieving the same semantics by changing the structure of
your code.


Well it is high priority because the exception has to be caught.


have throws statements in each catch block, but this is not recommended.


Correct, but there must also be an exception handler to catch the thrown
exception, and that could be the problem your experiencing.

HTH
AAA

On the other hand, if you have no handler, it is caught by the JVM;
so maybe it should be low priority.

 

[VisionSet]

Just been playing with RefactorIT
Found the Audit tool and ran it.

It alerted me to something that I never considered to be a problem.

It graded high priority - throwing clauses in a finally block.

Why do they see this as a problem? How bad is it?

My Joshua Bloch Bible doesn't say anything about it.

I can see that alerting the situation is good, but High Priority?

So how do you typically avoid throws in a finally?

And any how, if the method is declared as throws....
Then the finally block can throw it anyway.

 

[David Hilsee]

Just been playing with RefactorIT
Found the Audit tool and ran it.

It alerted me to something that I never considered to be a problem.

It graded high priority - throwing clauses in a finally block.

Why do they see this as a problem? How bad is it?

My Joshua Bloch Bible doesn't say anything about it.

I can see that alerting the situation is good, but High Priority?

So how do you typically avoid throws in a finally?

And any how, if the method is declared as throws....
Then the finally block can throw it anyway.

I can't think of a reason why one should be concerned about finally blocks
that throw exceptions. If you consider the plethora of code that contains
stuff like

finally {
foo.close(); // throws IOException or something else
}

it seems almost avoidable.

Now, if you are referring to explicitly throwing an exception (e.g. "throw
new FooException()") in a finally block, then I could see how that could be
considered odd, but I don't see how it is more of a problem than the
"finally close" example I just gave.

 

[Sebastian Millies]

[...]
In my experience, initialization to null of references is done by C/C++
programmers who don't understand why it's a bad idea in Java/C#.

Ahm, I guess I'm among those people, too. I always thought it was
unnecessary to explicitly initialize instance and local variables, but
also found code that did it easier to read, and continued with this
practice. So why exactly is this a bad idea?

(Perhaps this is better asked on c.l.j.help, but as the point came up in
this thread, I'll just ask here.)

Thanks, Sebastian

 

[VisionSet]

[...]
In my experience, initialization to null of references is done by C/C++
programmers who don't understand why it's a bad idea in Java/C#.

Ahm, I guess I'm among those people, too. I always thought it was
unnecessary to explicitly initialize instance and local variables, but
also found code that did it easier to read, and continued with this
practice. So why exactly is this a bad idea?

(Perhaps this is better asked on c.l.j.help, but as the point came up in
this thread, I'll just ask here.)

Because as soon as you initialise a local variable, you sever the help from
the compiler. Of course you soon operate under the same logic as the
compiler, but it is a handy fall back with complex conditionals.

 

[Timo Kinnunen]

If you're using JDBC then you always want to release
resources in a finally block. If something catastrophic has occured
(e.g. database crash) then anything you try to do subsequently will
fail. But only by closing everything can you release resources.
This gives rise to code like this:

(code snipped)

I don't know the intricacies of the JDBC specification, but in the general
case, I'd improve that by closing and nullifying the resources inside the
try block. This way, if the resource caches modifications, I won't swallow
the exception in the finally block.