Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > what's the point in finally?

Reply
Thread Tools

what's the point in finally?

 
 
Crouchez
Guest
Posts: n/a
 
      08-07-2007
try{
//blah }
catch(Exception ex){
// }
finally{ //do something }why not justtry{//blah}catch(Exception
e){}//do something


 
Reply With Quote
 
 
 
 
bugbear
Guest
Posts: n/a
 
      08-07-2007
Crouchez wrote:
> try{
> //blah }
> catch(Exception ex){
> // }
> finally{ //do something }why not justtry{//blah}catch(Exception
> e){}//do something
>
>


What if your exception handling code throws an Exception?

BugBear
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      08-07-2007
Crouchez wrote:
> try{
> //blah }
> catch(Exception ex){
> // }
> finally{ //do something }why not justtry{//blah}catch(Exception
> e){}//do something


For one thing, the finally clause will execute no matter
how the try-ed code terminates: By throwing an Exception, by
throwing some other kind of Throwable, by return-ing or by
break-ing or by running all the way to its end -- the code
in the finally clause will be executed regardless.

Another point is that it is almost always wrong to catch
Exception: You should catch IOException or InterruptedException
or some other, more specific kind of condition (or conditions).
The code in a catch clause is supposed to "deal with" the
exceptional condition, which means you need to have anticipated
the possibility and written code expressly for that outcome. It's
just not possible to "deal" effectively with every possible kind
of Throwable, so it's pretty much a given that some kinds of
Throwable will not be caught. Would you like your cleanup code
to execute anyhow? Then put it in the finally clause.

Still another issue: Once you catch an Exception, that's the
end of the line; Java's processing of it ceases once it's caught.
So what do you do if you'd like to clean up "en passant" but
let the original Exception propagate outward to your caller?
You could re-throw the same Exception after cleaning up, or
you could wrap the caught Exception in a new Exception of your
own and throw that one instead, but both courses are clumsy.
(The second is sometimes forced upon you for other reasons.)
Put your cleanup code in the finally clause and you get exactly
the desired effect without the extra running around.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Michael Jung
Guest
Posts: n/a
 
      08-07-2007
bugbear <bugbear@trim_papermule.co.uk_trim> writes:
> Crouchez wrote:
> > try{
> > //blah }
> > catch(Exception ex){
> > // }
> > finally{ //do something }why not justtry{//blah}catch(Exception
> > e){}//do something

>
> What if your exception handling code throws an Exception?


In fact, if you throw an exception in the finally block you have a much
toughre problem at hand. finally is used, e.g., to free resources in the good
and the bad case. Or implement some code that should be executed regardless of
whether you want the caller to get an exception or not.

Consider try blocks without catch but with finally or whithout finally but
catch.

Michael
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      08-07-2007
what if you throw an exception you DON'T catch?
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Crouchez
Guest
Posts: n/a
 
      08-07-2007
Scenario A

try{
//blah
}
catch(Exception e){
}
finally{
//do something
}

why not just...

Scenario B

try{
//blah
}catch(Exception e){
}
//do something


OK right. I'm not following the arguments here. The //do something will
always be called in both scenarios unless something isn't returned in the
catch method? I don't understand why there is more use of resources either
in Scenario B? So what's the use of finally?





 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      08-07-2007
Crouchez wrote:
> Scenario A
>
> try{
> //blah
> }
> catch(Exception e){
> }
> finally{
> //do something
> }
>
> why not just...
>
> Scenario B
>
> try{
> //blah
> }catch(Exception e){
> }
> //do something
>
>
> OK right. I'm not following the arguments here. The //do something will
> always be called in both scenarios unless something isn't returned in the
> catch method? I don't understand why there is more use of resources either
> in Scenario B? So what's the use of finally?


In the second scenario //do something will not be called if, for
example, there was a stack overflow, because StackOverflowError does not
extend Exception.

Also consider the case in which //blah contains a return statement. Code
immediately after the try-catch-finally will not get executed. The
finally block will.

Second, catching and hiding Exception is such a dangerous thing to do
that I don't really care whether finally is or is not needed in such
code. I'm much more interested in:

try{
// blah
}
catch(SomeException e){
// Do something about it
}
catch(AnotherException e){
// Do something else
}
finally{
// Clean up after blah
}

In this, much more realistic, case there may be exceptions that do not
get caught, and with non-trivial catch blocks the catch blocks
themselves may return or throw exceptions of their own. As before, none
of the errors are being caught, and blah may contain a return statement.

Most of the very, very few gotos I wrote when I was programming in C
were substitutes for finally - situations in which there were a lot of
logical returns, but some clean-up code that had to be run on the way
out, regardless of why the function was finishing.

Patricia
 
Reply With Quote
 
Crouchez
Guest
Posts: n/a
 
      08-07-2007

"Patricia Shanahan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Crouchez wrote:
>> Scenario A
>>
>> try{
>> //blah
>> }
>> catch(Exception e){
>> }
>> finally{
>> //do something
>> }
>>
>> why not just...
>>
>> Scenario B
>>
>> try{
>> //blah
>> }catch(Exception e){
>> }
>> //do something
>>
>>
>> OK right. I'm not following the arguments here. The //do something will
>> always be called in both scenarios unless something isn't returned in the
>> catch method? I don't understand why there is more use of resources
>> either in Scenario B? So what's the use of finally?

>
> In the second scenario //do something will not be called if, for
> example, there was a stack overflow, because StackOverflowError does not
> extend Exception.
>


are you sure? whether code throws an exception/error/throwable or not it
will still get to //do something in both scenarios. With StackOverflowError
or OutofMemoryError then the program often stops completely.

> Also consider the case in which //blah contains a return statement. Code
> immediately after the try-catch-finally will not get executed. The
> finally block will.
>


Ahh i see this point. I thought return was the ultimate last in the chain -
finally does indeed get called before return but i can't think of any reason
to do that.


 
Reply With Quote
 
Crouchez
Guest
Posts: n/a
 
      08-07-2007

"Crouchez" <(E-Mail Removed)> wrote in message
news:aI%ti.54073$%(E-Mail Removed). uk...
>
> "Patricia Shanahan" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Crouchez wrote:
>>> Scenario A
>>>
>>> try{
>>> //blah
>>> }
>>> catch(Exception e){
>>> }
>>> finally{
>>> //do something
>>> }
>>>
>>> why not just...
>>>
>>> Scenario B
>>>
>>> try{
>>> //blah
>>> }catch(Exception e){
>>> }
>>> //do something
>>>
>>>
>>> OK right. I'm not following the arguments here. The //do something will
>>> always be called in both scenarios unless something isn't returned in
>>> the catch method? I don't understand why there is more use of resources
>>> either in Scenario B? So what's the use of finally?

>>
>> In the second scenario //do something will not be called if, for
>> example, there was a stack overflow, because StackOverflowError does not
>> extend Exception.
>>

>
> are you sure? whether code throws an exception/error/throwable or not it
> will still get to //do something in both scenarios. With
> StackOverflowError or OutofMemoryError then the program often stops
> completely.
>
>> Also consider the case in which //blah contains a return statement. Code
>> immediately after the try-catch-finally will not get executed. The
>> finally block will.
>>

>
> Ahh i see this point. I thought return was the ultimate last in the
> chain - finally does indeed get called before return but i can't think of
> any reason to do that.
>
>


you're right with the StackOverflowError or OutofMemoryError thing - finally
does get called. Cheers for that


 
Reply With Quote
 
bugbear
Guest
Posts: n/a
 
      08-07-2007
Crouchez wrote:
> Scenario A
>
> try{
> //blah
> }
> catch(Exception e){
> }
> finally{
> //do something
> }
>
> why not just...
>
> Scenario B
>
> try{
> //blah
> }catch(Exception e){
> }
> //do something
>
>
> OK right. I'm not following the arguments here. The //do something will
> always be called in both scenarios unless something isn't returned in the
> catch method? I don't understand why there is more use of resources either
> in Scenario B? So what's the use of finally?


In your code there is no point in finally. If you had REAL exception handling,
i.e. non empty exception blocks (which you should), the distinction
may become more obvious.

BugBear
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Share-Point-2010 ,Share-Point -2010 Training , Share-point-2010Hyderabad , Share-point-2010 Institute Saraswati lakki ASP .Net 0 01-06-2012 06:39 AM
Scenario 5: IS-IS routing on Frame Relay Multi-point and Point-to-Point David Sudjiman Cisco 0 06-08-2006 09:11 AM
point to point protocol Gopi VHDL 1 07-13-2004 02:37 PM
simulate point-to-point with 2620's np Cisco 11 03-04-2004 01:44 AM
help, please!! cisco 827H point per point configuration javi Cisco 1 10-16-2003 07:33 AM



Advertisments