About Question enthuware.ocpjp.v8.2.1205 :

[Martyjee]

The explanation contains the following:

The code can be fixed by replacing both the exceptions with IOException.

No, because IOException is a subclass of IOException (itself!) the multi-catch will cause a compiler-error! Adding another catch-clause for IOException like in the code snippet below can fix the problem, or replace only FileNotFoundException with IOException in the multi-catch.

Code: Select all

catch (FileNotFoundException | IndexOutOfBoundsException e) {             
//file not found or some out of bounds exception
e.printStackTrace();        
} catch (IOException e) { 
//some other IO related problem
e.printStackTrace();
}

[admin]

Actually, it is trying to convey (unsuccessfully, apparently) that replacing FileNotFoundException | IndexOutOfBoundsException with just IOException will fix the problem.

HTH,
Paul.

[Martyjee]

But then you are writing off the IndexOutOfBoundsException.
Why are you trying to catch that exception in the first place? Why even use a multi-catch then?
A more plausible solution would be my solution. It even shows the ability to properly fix code without limiting (e.g., writing off the IndexOutOfBoundsException) the behaviour of a method.

I agree that removing the multi-catch altogether and replacing it with a single IOException will make the code compile, but my fix is much more elegant, wouldn't you agree? And it removes the ambiguity of using the word 'both' in the explanation of the question's answer!

Kind regards,

Martijn

[admin]

Yes, your solution will also work.

[Martyjee]

Dear Paul,

My last post wasn't about the correctness of my solution, but whether you find it a more elegant solution than the one presented. If you are not willing to adopt my solution, please explain!

I believe that the questions of Enthuware are of the highest quality and the explanation of the answers very detailed. I'm just trying to help you maintain that quality!

Kind regards,

Martijn

[admin]

I sincerely appreciate your feedback on improving the content.
But the question is not really asking about any solution. The statement that you are picking on is contained in the explanation and gives just one suggestion that can fix the code.

Yes, I agree, adding another catch block will be another solution. Regarding elegance, that depends on the requirements. Is it required to catch FileNotFoundException | IndexOutOfBoundsException separately and IOException separately, when all you are doing is e.printStackTrace()?

I don't think your solution is more elegant because you are mixing runtime and checked exceptions in the same catch block.

From elegance perspective, wouldn't the following will be even more elegant?

Code: Select all

catch (RuntimeException e) {             
e.printStackTrace();        
} catch (IOException e) { 
e.printStackTrace();
}

Because now you have separated runtime exceptions handing and io exceptions handling. Separating the two kinds gives the programmer an opportunity to take different course of action for checked and unchecked exceptions.


HTH,
Paul.

[Martyjee]

I don't think your solution is more elegant because you are mixing runtime and checked exceptions in the same catch block.

Well, I didn't come up with this mixture, the authors of the method did! I try to stay as close to the original method as possible.

I don't agree with your solution, because your solution will catch any runtime exception (like NullPointerException). That was clearly not intended by the original method (it only cared about IndexOutOfBoundsException). I just try to fix the code and it keep as close as possible to the (intended) functionality. In my case it will catch the intended exceptions (IndexOutOfBounds and FileNotFoundException) in the multi-catch, and in addition catch the required IOException.

I do agree with you that maybe the word 'elegant' is not appropriate in this context. I agree that there is nothing elegant to the fact that all you do is print a stack trace. But you have to agree that my solution stays closer to the intended functionality than either your solution or the solution presented by the test studio!

BTW, I'm not trying to be stubborn, I just want to make a point. If you give a possible solution to fix some code in the test studio, why make that fix limit the method's functionality if you can just propose a solution that stays closer to the methods original behaviour?

HTH,

Martijn

[admin]

You could change RTE with IOOBE if you like, but I agree with the point that you are making. Will update the explanation to include your suggestion.

thank you for your feedback!
Paul.