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

discover if file exists

Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

i am working on project Euler problems. i have correctly and quickly answered 1,2,3 and 5
i created a simple GUI, and used a try/catch block to catch NullPointerExceptions if the user chooses one i haven't solved.

i solve each problem with a top level class that implements the following interface

this is all fine and good so far but what about when i solve 100 or more problems? then i have that many individual lines of code to put entries into my map. i would like to do this in a for loop. maybe even the same loop where i initialize the JComboBox. how do i find out if the class file exists before i try putting an entry in the map?

P.S. all the files are in the default package(same folder)


SCJP
Visit my download page
William P O'Sullivan
Ranch Hand

Joined: Mar 28, 2012
Posts: 859

Use Class.forName(...)


If "Solver" exists, add it to the map.

WP
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:used a try/catch block to catch NullPointerExceptions if the user chooses one i haven't solved.


Don't do that. NPE indicates a bug in your code and should not generally be caught.

If null is a valid state meaning "not there yet" and you can continue processing, then simply test for null, e.g. if (whatever == null) (or !=, depending on your logic).
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

William, that looks like the answer.
Jeff, did you read the code? i don't see how to do it the way you suggest. the way i am doing it seems fine to me.
NPE indicates a bug in your code and should not generally be caught.

i agree but i consider this an exception
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:William, that looks like the answer.
Jeff, did you read the code? i don't see how to do it the way you suggest. the way i am doing it seems fine to me.
NPE indicates a bug in your code and should not generally be caught.

i agree but i consider this an exception


You mean this?



I assume the NPE is coming because choice is null, due to map not containing that key? If so, then just do if (choice == null).

Or is it because choice.solve() returns null and output.setText doesn't like a null argument? In that case, assign the results of choice.solve() to a variable and test that variable for null.

In any case, there's definitely nothing there to suggest that catching NPE is valid here.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

no, it seems to me that as soon as this line gets executed
Problem choice = map.get(problems.getSelectedItem());
the exception will be already thrown before i can check

anyway i figured out the original problem. it could be simplified maybe but it is working
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19785
    
  20

Never just ignore exceptions like that. The least you should do is print the stack trace.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:no, it seems to me that as soon as this line gets executed
Problem choice = map.get(problems.getSelectedItem());
the exception will be already thrown before i can check


No it won't. What you're describing sounds like problems.getSelectedItem() is returning null, so you should check that.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:


MY EYES! THE GOGGLES DO NOTHING!
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

Rob, i didn't ignore it i posted a message to the GUI
Jeff, no that will never return null. map.get() is returning the null.
once i solve all the 379 problems there won't be any exceptions will there?
anyway it works just fine, and i have now solved #6 and #7 as well
some help simplifying my new initComponents()(if possible) would be appreciated
any other comments are welcome as well
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:
Jeff, i just don't understand


Don't understand what?

once i solve all the 379 problems there won't be any exceptions will there?


You can't generally predict that a given exception will or will not occur. An empty catch block says, "If something goes wrong, just pretend it didn't, and keep on going as if everything is fine." And catching Exception, as opposed to the specific checked exceptions that can be thrown, is generally not a good idea. For one thing, Exception includes the unchecked exceptions RuntimeException and its descendants, which you shouldn't be catching.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

but the catch block in question is not empty. it gives a message(the one in actionPerformed())
the message says to try a different choice
the other try catches are in initComponents() and i am hoping to simplify that
those were forced on me by the compiler
the one in actionPerformed() was a conscious choice by me
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:but the catch block in question is not empty.


The two I copy/pasted are.

it gives a message(the one in actionPerformed())


The one where you catch NPE? I've already explained why that's wrong and how to change it.

Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

when the compiler forces you to catch an exception(checked), that you know will not occur, what are you to do but provide an empty catch
as for the NPE: Problem choice = map.get(problems.getSelectedItem());
it seems to me the exception is thrown before i can check
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
Randall Twede wrote:when the compiler forces you to catch an exception(checked) what are you to do but provide an empty catch

You should properly handle the exception - at the very least print a message to where you will see it. Why would you want to pretend that nothing happened if there is in fact an exception?

as for the NPE: Problem choice = map.get(problems.getSelectedItem());
it seems to me the exception is thrown before i can check

No. You can check whether "problems" is null before you invoke a method on it. Then you can check whether "problems.getSelectedItem()" is null before you use it. It's perfectly fine to break nested statements like this one apart in order to make code easier to understand, and easier to debug.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

problems.getSelectedItem() will never be null
it is map.get() that can return null
by the time i ask if(choice == null) the exception will already have been thrown right?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:problems.getSelectedItem() will never be null
it is map.get() that can return null


So test its result:




by the time i ask if(choice == null) the exception will already have been thrown right?


No, because you haven't tried to dereference a null pointer. Simply getting a null result from a method call and assigning it to a variable doesn't give NPE.

And if the above code gives NPE, then either problems is null or problems.getSelectedItem() is and you're using a Map implementation that throws NPE on a call to get(null).
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:when the compiler forces you to catch an exception(checked), that you know will not occur, what are you to do but provide an empty catch


Log it at the very least. Or better yet, throw an unchecked exception, such as IllegalStateException or AssertionError, because something has happened that you didn't think could happen, so either your reasoning was faulty or there's a problem with the JVM, and either way, I'd want to know about it.

as for the NPE: Problem choice = map.get(problems.getSelectedItem());
it seems to me the exception is thrown before i can check

No, it's not.

You can check problems.

You can check problems.getSelectedItem().

You can check choice.

Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
Randall Twede wrote:by the time i ask if(choice == null) the exception will already have been thrown right?

That's the beauty of handling exceptions properly, i.e. at least printing out the stack trace - it tells you in which line of code the exception happens, so there's no guessing what might or might not cause the exception.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

i apologize for being so boneheaded. Jeff was right. i was under a misconception that the map was throwing the exception when it couldn't find the entry. sort of like the way an array will throw an IndexOutOfBounds exception. i should have at least tried it before continuing to argue.

as for the try catches in initComponents(), i simplified that to just one try catch. why catch them separately if i am just going to ignore them anyway. in this case ignoring them is the correct action. if one is thrown i just want to ignore it and continue the loop. here is the finished code.

i really like this design. especially using a map and interface. could you imagine what actionPerformed() would look like if i used a switch or if else?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:
as for the try catches in initComponents(), i simplified that to just one try catch. why catch them separately if i am just going to ignore them anyway.


Two problems with that:

1) You won't even know that something went wrong. You should at least be logging that the exceptions happened, and if you find that they're happening a lot, then you probably have a more serious problem.

2) Catching Exception catches RuntimeException and its subclasses, which you shouldn't do in most cases. Especially you shouldn't catch and ignore them, because that just says, "Ignore any bugs in my code. Pretend the code is bug-free and go on as if it were."

in this case ignoring them is the correct action.


Not for unchecked exceptions it's not.

Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

i am checking for existence of 379 possible files. so far only 6 exist. it is going to throw an exception more often than not. but i will think about what you said.

is there a way to catch only checked exceptions?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:i am checking for existence of 379 possible files. so far only 6 exist. it is going to throw an exception more often than not. but i will think about what you said.


Are you talking about Class.forName()? In a real application, I'd at least have a log.debug() or log.info() call to let me know it failed. Exceptions are supposed to be, well, exceptional. If they're the rule rather than the exception, then you may need to rethink your design.

If only 6 of 379 are going to be there, then I would look for a different approach, such as explicitly naming the 6 that I expect to find. Or something. I would try very hard to avoid writing code that is expected to fail 98% of the time.

If, on the other hand, when you say "so far," you mean that eventually all of the 379 will be there, and you're just testing with 6 for now to keep it simple, then it sounds like you're expecting all 379 to be there, so you definitely don't want to just ignore the exception.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

well, i really don't think i can solve all 379 euler problems but one can hope

is there a way to catch only checked exceptions?
ill check the API to find that out.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:
is there a way to catch only checked exceptions?


No, but there shouldn't be that many that are thrown.

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

I think a better approach would be to simply have a .properties file or something that lists the classes that are present, rather than hardcoding the assumption that they'll all be there. Especially since, as you yourself pointed out, it is unlikely that they will be.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

you are right there are only 3 that can be thrown
i also think you are right that runtime exceptions should not be caught
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19785
    
  20

Randall Twede wrote:is there a way to catch only checked exceptions?

There isn't, but there is a workaround:
It's better to catch the specific exceptions of course.

Jeff Verdegan wrote:

So close, yet so far
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

yeah i probably should do that just for principle. but i thought about it for a while, and the code in my try block can't throw a runtime exception. or for that matter any but the three the compiler told me about. and in this situation i want to ignore exceptions. i did change the code a little though. just to remind me this is not a good practice.

catch(Exception e) //i can get away with it
{
}
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

on second thought i think i will go with
catch (E1 | E2 | E3 e) since i have java7
it will make it clear what exceptions are being caught.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Randall Twede wrote:yeah i probably should do that just for principle. but i thought about it for a while, and the code in my try block can't throw a runtime exception.


That's a dangerous assumption to make. It says, "My code is 100% bug free, and all other classes I am using form the core API and thirdparties are 100% bug free, and the JVM is 100% guaranteed not to encounter any problems due to either resource issues or its own bugs."

In short: Any code can throw an unchecked exception.


or for that matter any but the three the compiler told me about.


Which you shouldn't ignore, any more than you should ignore the unchecked exceptions that can occur.

and in this situation i want to ignore exceptions. i did change the code a little though. just to remind me this is not a good practice.

catch(Exception e) //i can get away with it
{
}


Why? What benefit do you think you gain by pretending exceptions can't happen, and ignoring them when they do? What would the cost to you be to simply print the stack trace when it happens, or even just log the exception name?

I'm sure by now you think I'm just nagging you and beating a dead horse, but you seem hell-bent on making a point of writing fragile code that ignores best practices, and the only reason I can see for doing so is because it's the easiest fit with a decidedly inappropriate design.
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

it is amazing how a very small change can make a very big improvement. i realized that since i am now checking if the class files exist i can move this line
problems.addItem(name);
into the try block. now the JComboBox only contains items that correspond with solved problems. sooooo much better! and of course i don't need the if else in actionPerformed() anymore.


i just realized i probably don't need a ScrollPane for this program(copy and paste from a similar program) but it doesn't hurt anything
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: discover if file exists