• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RR#68 & #69

 
Ranch Hand
Posts: 182
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"If there is no return statement in the catch or finally blocks, execution continues with code following the finally block" --Ivor Horton's BJ2 pp.303 I am confused...isn't this more or less the sequence if either block HAS a return statement. For example, are the following statements correct about the code below?
try{ // throws exception }
catch{ // processes exception }
finally{ // executes after try or try&catch block }
??If a return statement is executed in the catch block, the code leaves the catch block, executes through the finally block, then continues with code following the finally block??
??If a return statement is executed in the finally block, the code leaves the finally block and continues with code following the finally block??
Then Mr. Horton's words seemed to contradict Rules Roundup#68 -- "An exception uncaught in a method is always propagated upwards to the calling method. It'll continue to propagate up through each level of calling method until it's either caught, or it reaches the highest-level method. If still not caught, the prog terminates and a suitable message is displayed." (pp. 305) This seems opposite of RR#68, which says that if an exception is not caught, the finally block will run and the rest of the method is skipped.
Please explain the two questions above, surrounded by ??'s. Also, can I look at some working code that demonstrates an uncaught exception propagating up through the ranks? Is there some kind of method() hierarchy or something?

I might as well include RR#69, which says that an overloaded method() must change the argument list. Doesn't it actually mean that an overloaded method() must change the parameter list? (the parameter list is in parenthesis) SteveII
 
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, the basic principle here is that if you have a final-black after your try, that will be executed nomatter what happends, that is wheter there is an exception or not.
Whith me so far? Ok.
As for try-catch, look at the following:

In the example here, if the code part of mathod1() where to throw en exception of type Exception_type_2, the catch-block of the method would catch it. If it where to throw Exception_type_1 instead, the throw would "travel up" to the try-catch surrounding the call to method1(). If some other type where thrown, it would continue travel up, until it was caought or it reaches the top of the porogram.
Does this explain it?
/Mike
 
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Steven, RR#69 -- argument list is synonymous with parameter list. I think argument is the more frequently used term in these discussions.
 
Steven YaegerII
Ranch Hand
Posts: 182
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the confirmation, Scott. I'm slowly getting used to accepting both terms ("list" gives it away).
Mikael, that does alot to simplify things...a thrown exception just looks for the code that can catch it. I was pulling some ridiculous ideas from that reading last night.
Are my two assumptions in the original post correct (surrounded by ??'s) ?
Thanks all!
 
Mikael Jonasson
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not entierly:
if there is a returnstatement in the catch-block, the final-block will run, but no code after it.
I'm not realy sure what happends if you put a return in the finalblock, except that it wont run any code after it.
The rule is that a return statement leaves the mathod directly. Directly however is redefined to mean that the finalblock will be executed.
The only way of leaving the method without running the finalblock would be to put the return in the try-block. Don't think the final-block will be runned then (am I wrong?)
/Mike
 
Steven YaegerII
Ranch Hand
Posts: 182
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks again. I don't if a return in the try block will prevent a finally block from running, but I'll code it after I'm finished the latest problem. I do know that a prog will exit, without the finally block executing by placing System.exit(0) before it.
 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,Mikael:
Actually to put the return statement in the try-block,the finallyblock also be executed.You can try it!

Originally posted by Mikael Jonasson:
Not entierly:
if there is a returnstatement in the catch-block, the final-block will run, but no code after it.
I'm not realy sure what happends if you put a return in the finalblock, except that it wont run any code after it.
The rule is that a return statement leaves the mathod directly. Directly however is redefined to mean that the finalblock will be executed.
The only way of leaving the method without running the finalblock would be to put the return in the try-block. Don't think the final-block will be runned then (am I wrong?)
/Mike



------------------
 
Scott Appleton
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
However, if you stick a return statement ahead of other code within the same portion of the block, you will get an Unreachable Statement compiler error. The return has to be inside some sort of conditional block (though something as simple as "if (true) return;" does compile). Interestingly, this applies even in the case where the return is the final statement in a finally block, but there is code after the try-catch-finally block.
Steven, your initial post gave me some questions about this topic as well, so I played around with some code and pretty much validated what Michael and William said -- a return within a try or catch will send execution straight to the finally block and then leave the method, even if there is more code in the method after the try-catch-finally. If the return is in the finally block, execution will leave the method immediately, again without executing any remaining code in the try-catch-finally block.
 
reply
    Bookmark Topic Watch Topic
  • New Topic