Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Is there any sense in using final keyword in catch block?

Reply
Thread Tools

Is there any sense in using final keyword in catch block?

 
 
Royan
Guest
Posts: n/a
 
      10-23-2008
The question is simple, does it make sense to add final keyword like
in the example below?

try {
// code
} catch (final XxxxException e) {
// do exception handling
}

Whether it makes sense or not, please justify your answer.
 
Reply With Quote
 
 
 
 
RedGrittyBrick
Guest
Posts: n/a
 
      10-23-2008

Royan wrote:
> The question is simple, does it make sense to add final keyword like
> in the example below?
>
> try {
> // code
> } catch (final XxxxException e) {
> // do exception handling
> }
>
> Whether it makes sense or not, please justify your answer.


Homework?

--
RGB
 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      10-23-2008
Royan wrote:
> The question is simple, does it make sense to add final keyword like
> in the example below?
>
> try {
> // code
> } catch (final XxxxException e) {
> // do exception handling
> }
>
> Whether it makes sense or not, please justify your answer.


Does it make sense to add the final keyword to a local variable?

Do you know what the ramifications of doing so are?

If you can answer those two questions, you should be able to translate
the semantics of the final keyword to the example and explain why it
would or would not make sense.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Royan
Guest
Posts: n/a
 
      10-23-2008
On 23 , 18:44, Joshua Cranmer <(E-Mail Removed)> wrote:
> Royan wrote:
> > The question is simple, does it make sense to add final keyword like
> > in the example below?

>
> > try {
> > // code
> > } catch (final XxxxException e) {
> > // do exception handling
> > }

>
> > Whether it makes sense or not, please justify your answer.

>
> Does it make sense to add the final keyword to a local variable?
>
> Do you know what the ramifications of doing so are?
>
> If you can answer those two questions, you should be able to translate
> the semantics of the final keyword to the example and explain why it
> would or would not make sense.
>
> --
> Beware of bugs in the above code; I have only proved it correct, not
> tried it. -- Donald E. Knuth


Guys this is a serious question and is actually aimed to reveal any
JIT optimizations (if any), best practices or whatever.

I've read a couple of articles regarding the usage of final keyword,
and to the moment the most interesting point I've read regarding its
usage in the catch block was about upcoming changes in java. Check out
this article: http://weblogs.java.net/blog/emcmanu...ne_report.html
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      10-23-2008
Royan wrote:
> The question is simple, does it make sense to add final keyword like
> in the example below?
>
> try {
> // code
> } catch (final XxxxException e) {
> // do exception handling
> }
>
> Whether it makes sense or not, please justify your answer.

It is often a stylistic thing. My personal style is to make fields and
local variables final, but leave parameters/catch as not final.

This is completely arbitrary. My ideal would have been if Java had made
every field/parameter/local final by default, and the programmer could
specific nonfinal for things they really wanted to change.



--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      10-23-2008
Royan wrote:
> Guys this is a serious question and is actually aimed to reveal any
> JIT optimizations (if any), best practices or whatever.


Your original question sounds copied verbatim from some homework
assignment. As I said earlier, a final in a catch statement means the
same as any other final local variable.

> I've read a couple of articles regarding the usage of final keyword,
> and to the moment the most interesting point I've read regarding its
> usage in the catch block was about upcoming changes in java. Check out
> this article: http://weblogs.java.net/blog/emcmanu...ne_report.html


That's not upcoming changes:
"They followed with two proposals for exception handling..."

I doubt that the second proposal (the one that changes the implication
of final) would be accepted over the first one.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      10-23-2008
Daniel Pitts wrote:
> Royan wrote:
>> The question is simple, does it make sense to add final keyword
>> like
>> in the example below?
>>
>> try {
>> // code
>> } catch (final XxxxException e) {
>> // do exception handling
>> }
>>
>> Whether it makes sense or not, please justify your answer.

> It is often a stylistic thing. My personal style is to make fields
> and local variables final, but leave parameters/catch as not final.
>
> This is completely arbitrary. My ideal would have been if Java had
> made every field/parameter/local final by default, and the
> programmer
> could specific nonfinal for things they really wanted to change.


for (nonfinal int i = 0; i < 10; i++)

Yup, a *big* improvement.


 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      10-23-2008
On Thu, 23 Oct 2008, Mike Schilling wrote:

> Daniel Pitts wrote:
>> Royan wrote:
>>
>>> The question is simple, does it make sense to add final keyword like
>>> in the example below?
>>>
>>> try {
>>> // code
>>> } catch (final XxxxException e) {
>>> // do exception handling
>>> }
>>>
>>> Whether it makes sense or not, please justify your answer.

>> It is often a stylistic thing. My personal style is to make fields
>> and local variables final, but leave parameters/catch as not final.


My style is to not use final for local variables (including parameters and
catch variables) at all. Unless they're being closed over by an anonymous
class, where it's required. I think the point of a final qualifier is to
reassure the programmer (reading or writing the code) that it won't change
unexpectedly - it's an aid to reasoning about the code. Instance variables
can be read and written from anywhere in the class (or even outside, if
they're not private), and thus in a class of more than trivial size, it
can be hard to keep track of whether that's happening, and where.
Declaring a field final eliminates this difficulty at a stroke. However,
local variables can only be accessed from inside the method they're local
to; that's a much smaller body of code that the programmer has to keep in
mind to know everything about the variable's use. There, i don't think
there's much uncertainty to be reduced, and the additional keywords just
clutter up the screen and mean more letters to type.

Note that for this analysis to hold, your methods have to be short: small
enough that you can hold the whole thing in your mind at once. However, i
would say that this is exactly how methods should be. If your method is
big enough that making its locals final is helping you, then you need to
split it up into multiple smaller methods. Essentially, final locals are a
code smell.

>> This is completely arbitrary. My ideal would have been if Java had
>> made every field/parameter/local final by default, and the programmer
>> could specific nonfinal for things they really wanted to change.


I quite like this idea too. I'd want to see how it felt in practice before
i fully supported it, though.

> for (nonfinal int i = 0; i < 10; i++)
>
> Yup, a *big* improvement.


Even better, IMHO:

for (variable int i = 0; i < 10; i++)

!

tom

--
Virtually everything you touch has been mined. -- Prof Keith Atkinson
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-23-2008
Tom Anderson wrote:
> My style is to not use final for local variables (including parameters and
> catch variables) at all. Unless they're being closed over by an anonymous
> class, where it's required. I think the point of a final qualifier is to
> reassure the programmer (reading or writing the code) that it won't change
> unexpectedly - it's an aid to reasoning about the code. Instance variables
> can be read and written from anywhere in the class (or even outside, if
> they're not private), and thus in a class of more than trivial size, it
> can be hard to keep track of whether that's happening, and where.
> Declaring a field final eliminates this difficulty at a stroke. However,
> local variables can only be accessed from inside the method they're local
> to; that's a much smaller body of code that the programmer has to keep in
> mind to know everything about the variable's use. There, i don't think
> there's much uncertainty to be reduced, and the additional keywords just
> clutter up the screen and mean more letters to type.


There are also implications of 'final' for thread safety.

--
Lew
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      10-23-2008
Lew wrote:
> Tom Anderson wrote:
>> My style is to not use final for local variables (including parameters and
>> catch variables) at all. Unless they're being closed over by an anonymous
>> class, where it's required. I think the point of a final qualifier is to
>> reassure the programmer (reading or writing the code) that it won't change
>> unexpectedly - it's an aid to reasoning about the code. Instance variables
>> can be read and written from anywhere in the class (or even outside, if
>> they're not private), and thus in a class of more than trivial size, it
>> can be hard to keep track of whether that's happening, and where.
>> Declaring a field final eliminates this difficulty at a stroke. However,
>> local variables can only be accessed from inside the method they're local
>> to; that's a much smaller body of code that the programmer has to keep in
>> mind to know everything about the variable's use. There, i don't think
>> there's much uncertainty to be reduced, and the additional keywords just
>> clutter up the screen and mean more letters to type.

>
> There are also implications of 'final' for thread safety.


It is truly unfortunate that Java hasn't the same concept of "const
reference" that C++ does. It would make Java code so much easier to
verify as thread-safe and otherwise bug-free.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
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
Any sense in using private static final for non-static classes? Ricardo Palomares Martinez Java 2 04-28-2007 10:45 PM
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
Difference between static final members and final static members(if any)? JFCM Java 4 02-07-2006 11:32 AM
Does the typename keyword make sense here? Exits Funnel C++ 1 01-08-2005 06:56 AM
Does pervasive use of final make sense? Timo Nentwig Java 31 05-13-2004 09:33 PM



Advertisments