I'm not sure why you'd want to use a catch, but I agree there is more than one way to solve the problem. I was merely pointing out one thing that would prevent the code from passing the test framework.
Sorry, I didn't think I was telling you something which you didn't already know. I just saw a hole in the pedantry and felt a strange need to point it out. Now that I've typed that, I realize what a horrible person I am.
As to why you'd want to use a catch, I think it's kind of sloppy to let the user see an uncaught exception. You might as well just do
public static void main(String args[]){
try {
...
} catch (Exception e) {
System.out.println("This is horrible software, and you shouldn't use it.");
}
}
... as that's what many users already see when exception goes uncaught.
I could see a try/catch with a System.exit(-1) maybe, but arguably the default handler does the right thing (returns an error code and writes diagnostics to stderr).
> He wrote the code to show you that you don't need to import IOException you can use a catch all to avoid a throws statement in the method header.
You're conflating two things. I could just as easily have caught Throwable or Exception and not needed the import. The question is: what would you actually put in the handler that would be so much better? The actually provided sample code is much worse, as it prints to System.out instead of System.err, and it doesn't report an error to the parent process, so you muddy up the output (imagine if the file you were copying actually ended in "This is horrible software, and you shouldn't use it.", how would you even know) and there is not a terribly easy way to detect an error happened.
> This is bad code as he said.
It's not bad code to declare a static exception as escaping your method, particularly if you don't have any logic for handling it. It's bad code to have an exception handler that doesn't.
