• Post Reply Bookmark Topic Watch Topic
  • New Topic

final variable try/catch dilemma  RSS feed

 
Marcus Kelvin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is it possible to set a final variable in a constructor try catch block?



The logic is such that if the try fails, x will not have been initialized. However, the compiler cannot determine that, and so gives a "x might already have been assigned" error. Is there a way out of this, or do I have to settle for the field not being final?

 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could create a helper method that handles the exception:
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marcus Kelvin wrote:Is it possible to set a final variable in a constructor try catch block?



The logic is such that if the try fails, x will not have been initialized. However, the compiler cannot determine that, and so gives a "x might already have been assigned" error. Is there a way out of this, or do I have to settle for the field not being final?



IMO, the best work-around, when the implementation to calculate a value for the final variable, can't do it with a single assigment, is to use a temp variable. Use a local temporary variable, and upon leaving the constructor, assign the final variable.

[EDIT: beaten to the answer again -- or at least, a variant of it]

Henry
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you provide a more realistic explanation of what you're really trying to accomplish? Why do you want to catch the exception and then set a final variable to an "uninitialized" state? It seems like it would just be better to let the constructor throw the exception. If this variable is a member and final, then it's a necessary part of the state of your object, and you shouldn't be using the object if you couldn't set it.
 
Marcus Kelvin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Three good suggestions, thanks!

Jeff Verdegan wrote:Can you provide a more realistic explanation of what you're really trying to accomplish? Why do you want to catch the exception and then set a final variable to an "uninitialized" state? It seems like it would just be better to let the constructor throw the exception. If this variable is a member and final, then it's a necessary part of the state of your object, and you shouldn't be using the object if you couldn't set it.


It's actually not necessary (eg, it could be purposefully set null as well), but the user should know that it occurred unintentionally, so I like that idea. Although the root exception is I think too ambiguous, the compiler does notice chaining and accepts this:



 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marcus Kelvin wrote:Although the root exception is I think too ambiguous,


I said exception, with a lowercase "e", meaning the concept in general, not Exception with an uppercase "e", meaning that specific class.

Also, you shouldn't be catching Exception. you should catch only those checked exceptions that can actually be thrown, and let unchecked exceptions (RuntimeException, Error, and their descendants) bubble up to the caller. And of course, even those checked exceptions should only be caught if you're going to actually handle them (that is, actually fix the problem, which you usually can't do), or wrap and rethrow them (which it looks like you're doing).
 
Marcus Kelvin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:
Marcus Kelvin wrote:
Also, you shouldn't be catching Exception. You should catch only those checked exceptions that can actually be thrown, and let unchecked exceptions (RuntimeException, Error, and their descendants) bubble up to the caller. And of course, even those checked exceptions should only be caught if you're going to actually handle them (that is, actually fix the problem, which you usually can't do), or wrap and rethrow them (which it looks like you're doing).


Understood. I just did that here for brevity, the real version has a few catch blocks for the various specific flavours that the try could throw.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!