I am *really* having a hard time figuring out how a program flows when there's a throw/catch construct involved. Here is the code I was given to illustrate throw/catch:
//this is the first of two files
publicclass Splitter {
publicstaticvoid main(String[] arg) {
Splitter splitter = new Splitter();
try {
System.out.println(splitter.half(34));
System.out.println(splitter.half(12));
System.out.println(splitter.half(87));
System.out.println(splitter.half(92));
} catch(OddNumberException e) {
System.out.println(e);
}
}
publicint half(int value) throws OddNumberException {
int result = value / 2;
if((result * 2) != value)
thrownew OddNumberException(value);
return(result);
}
}
//here is the second file
publicclass OddNumberException extends Exception {
int number;
OddNumberException(int number) {
this.number = number;
}
public String toString() {
return(number + " is not an even number.");
}
}
The programs both compile fine, and the output is "17 6 87 is not an even number."
I'm trying to follow the flow of the program, and once it enters into the statement throwing an exception, I'm lost. I can see how the program goes in the first 2 cases in the try/catch block. Then on the 3rd statement, that if statement (if((result*2) != value)) in half() is true, so a new OddNumberException will be thrown. At this point, value=87, so this will be passed to the constructor in class OddNumberException and will be assigned to number. It's there where I start to lose my way.
How is toString() called at all?
Once Java has resolved what OddNumberException is, I would imagine control would return to the try/catch construct, the "catch" being the appropriate part - an OddNumberException is what is coded to be caught, that's what IS caught.
I don't see how e becomes equal to "87 is not an even number", tho, but that's what is printed out.
I was told that after executing the catch, the program continues and executes the code following the try/catch block. I tried coding a "finally" in there and found that this was indeed the case.
But the last command in the try block is never executed - 46 is never printed out, as I'd think it would be. Does command never return to the try part once the catch part has been executed? If it does, why doesn't it (or doesn't it seem to) in this case, and how should this program be modified to do so?
I thought command would return to the try part, that that was part of the rationale behind doing all your error management in one place, but I must be mistaken or I'm misunderstanding something that's rather important! Help, please!!
When an exception is thrown in try block then control goes to catch block (if catch block is available) and then control doesn't return to the following line of code in try block. If you have a finally block then after catch, finally block will be executed. If you don't have a finally block then code following the try-catch will be executed. Therefore, your code is executing correctly. Since you have an exception in try block the code (last line) following the code which threw exception will never get executed. The rationale behind try-catch is not to all handle errors at one place rather to separate error handling code from main code.
try {
line - 1
line - 2 throws exception Control moves to line 4
line - 3
}
catch ( Exception e ) {
line - 4 ; After this line control moves to line-5 not line 3
}
line - 5
If the first method call (scansrc.loadControlFile()) causes an exception to be thrown, I take it control will go from the try block to the appropriate catch block. After control leaves the catch block, if it never comes back to the try block and exits the whole try/catch/finally, what is the point of doing all this error processing in one place, apart from the code? And is there any way to get the code to go back to the try block, just after it threw the exception?
Sounds like maybe you are familiar with the Visual Basic resume that allows the exception handler to handle the problem, then resume execution at its location.
Most other languages, including Java, don't have this feature, so you have to handle it with with the granularity of your try/catch clauses. If you put the try clause around ten statements that may throw an exception and the first one does, then the other nine won't get a chance. If you wanted to be able to handle that first exception and let the other nine do their thing, then you'd put a separate try/catch around the first one.
So, in your example, if the scansrc.loadControlFile() method was likely to throw an exception which you could handle and from which you could likely recover, you might put it in a try of its own. You can even put a try/catch in a for-loop, in order to try it a few times (like allow a user to specify a file many times). It gets a little cumbersome, because even after your exception handler has given it a go (possibly many times), it may still not be able to handle it and you don't want to get stuck in an infinite loop. If you couldn't handle it, you also don't want the rest of the code (which assumes everything is in order) to continue processing, so after a certain number of attempts, you may throw your own (or the same) exception.
Previous Topic
