aspose file tools*
The moose likes Beginning Java and the fly likes Dead code in if block? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Dead code in if block?" Watch "Dead code in if block?" New topic
Author

Dead code in if block?

dirk dj jaeckel
Greenhorn

Joined: May 31, 2012
Posts: 22
Hello
the following code shows Dead code in Eclipse from line 20 to 38 ( i tried to underline but this doesnt work in code)

does eclipse assume that the variable fis can never have the value null ?
i have this problem at a lot of places always the same style of code so solving it would save me around 50 warnings!

please comment if you understand why this happens ;)

cheers
Dirk


Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

If the assignment on Line 16 is successful, then the condition on Line 19 will never, ever evaluate to true, therefore, there is no chance for the code you wanted to underline to execute. BTW, you can't put any other formatting tags inside [ code] tags.


Junilu - [How to Ask Questions] [How to Answer Questions]
dirk dj jaeckel
Greenhorn

Joined: May 31, 2012
Posts: 22
Junilu Lacar wrote:If the assignment on Line 16 is successful, then the condition on Line 19 will never, ever evaluate to true, therefore, there is no chance for the code you wanted to underline to execute. [ code] tags.


yes, but i think the code is there for the case the assignment on Line 16 is NOT succesfull ???

Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2376
    
  28

The only reason a new won;t be succesful is if there is an exception inside constructor (or a fatal exception in JVM). In both cases, control will never go to line 19.

Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4462
    
    6

Jayesh is right, see the JavaDocs for java.io.FileInputStream - the constructor will throw a FileNotFoundException. The Java compiler sees that and figures out that's the only reason for execution to skip Line 19 and go to the catch block. Your check for null on Line 19 is redundant. In general, checks for null should be reconsidered. It makes your code unnecessarily noisy with all the if (something == null). You should write tests and establish a design convention where nothing should return null if null is not a valid value. For example, methods that are declared to return a collection such as a List should be designed to return an empty list if nothing is there to populate the list, it shouldn't return a null value. That way, client code doesn't have to check for null all the time. If the class does in fact return null when asked for a List, then that becomes a bug in the class implementation.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3014
    
  10
Jayesh A Lalwani wrote:The only reason a new won;t be succesful is if there is an exception inside constructor (or a fatal exception in JVM). In both cases, control will never go to line 19.

There is also code called before the constructor is invoked - in this case, it's the "Settings.getInstance().getImagePath("moneyBackside")". But the same argument applies - if it throws an exception, control will never go to line 19. If it doesn't throw an exception, then line 19 does execute, and fis definitely has a non-null value.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2376
    
  28

Also, it looks like the code in your catch block is doing the same things that your code in try block is executing. That's quite a bunch of redundant code. If you have an exception in main code, your code in catch block will fail too.

Do not use Exception to handle cases that can be handled using validation. For example, if your case, you should first check if the FIle exists. If file exists, open the file in FileInputStream. If it doesn't exist, get the InputStream from the Classloader. The code that loads the Image from InputStream and draws the image doesn't have to be duplicated.
dirk dj jaeckel
Greenhorn

Joined: May 31, 2012
Posts: 22
Jayesh A Lalwani wrote:Also, it looks like the code in your catch block is doing the same things that your code in try block is executing. That's quite a bunch of redundant code. If you have an exception in main code, your code in catch block will fail too.

Do not use Exception to handle cases that can be handled using validation. For example, if your case, you should first check if the FIle exists. If file exists, open the file in FileInputStream. If it doesn't exist, get the InputStream from the Classloader. The code that loads the Image from InputStream and draws the image doesn't have to be duplicated.


thanks for your comments

that is not my code and i am new in java, thats why i did this post, i´ll go over it and post my result then here.

dirk dj jaeckel
Greenhorn

Joined: May 31, 2012
Posts: 22
Here is what i made of it, please comment ;)

as far as i could test it it works pretty fine:


Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2376
    
  28

You are still using exception handling where you should be using validation.

You can do this

dirk dj jaeckel
Greenhorn

Joined: May 31, 2012
Posts: 22
your code looks cleaner but doesn´t make anymore what was intended,
the try catch blocks are for getting the diffrence of application or applet
and when both have no internal resource then a load from a fixed path is tried,
thats what the comment of the original programmer says which is unfortunatly in german



Jayesh A Lalwani wrote:You are still using exception handling where you should be using validation.

You can do this

 
 
subject: Dead code in if block?