Hi there Lawrence
The main() method doesn't actually catch the exception - it throws it.
It is then up to the JVM to catch the exception and handle it - which
is why we
get the stack trace.
At least that is my understanding.
I put together some code for you to explore. Here are the two classes:
package wayne.riesterer.education.java;
import java.io.RandomAccessFile;
/**
* This class deliberately throws an EOFException which is not caught
in the
* mainMethodSimulator() method. For this reason, the exception is
passed back to
* the caller.
*
* The caller in this case is the main() method of the JVMSimulator
class.
*
* Please follow the number sequence.
*/
public class ThrowsExceptionClass {
// 4. The exception ends up here. The mainMethodSimulator doesn't
// actually catch the exception, it throws it...Lol.
public void mainMethodSimulator() throws Exception {
RandomAccessFile f = new RandomAccessFile("test.txt", "rw");
// 1. This will cause an EOFException
System.out.println(f.readInt());
// 2. The JVM looks for an EOFException catch block in this
// method, but can't find one
// 3. It looks for any superclass of EOFException such as
// IOException or Exception but can't find either
}
}
package wayne.riesterer.education.java;
import java.io.EOFException;
import java.io.IOException;
/**
* Please follow the sequence of steps to explore exception handling.
*/
public class JVMSimulator {
// 1. Run this method as is and study the stack trace. You can see
the
// path the exception has taken.
// 2. Remove the throws Exception clause from the main() method
declaration
public static void main(String[] args) throws Exception {
ThrowsExceptionClass erroneousClass = new
ThrowsExceptionClass();
// 3. Uncomment the try-catch block for Exception and run.
// Notice that the exception is handled and the
associated
// message is displayed.
// 4. Uncomment the try-catch block for IOException and run.
// Notice that the JVM has chosen the IOException handler as
being
// a better match to handle the exception (more specific),
so it
// executes that block instead of the code in the Exception
block.
// 5. Uncomment the try-catch block for EOFException and run.
// Notice that the JVM has now chosen this block, since that
was
// the exact exception that was caused by the readInt() call
// in the causeException() method of the
ThrowsExceptionClass.
//try {
erroneousClass.mainMethodSimulator();
//} catch (EOFException e) {
// System.out.println("This will execute as a first
choice.");
//} catch (IOException e) {
// System.out.println("This will execute as a second
choice.");
//} catch (Exception e) {
// System.out.println("This will execute as a last
resort.");
//}
}
}
<--------------------------------------------------------------------------------------------------
>
As for the second question, I'm only guessing that to use the
RandomAccessFile class for complex records, it may be necessary to
have fix length fields of known data types. Then you will always know
that a record will take up a particular number of bytes. Then, you
could read in the record using a method that makes a number of
read[DataType] calls to retrieve each of the fields from the file.
I'm only toying with ideas here and it seems a bit fuzzy without a
thorough exploration of it.
Is there any particular reason why you want to store data using this
method - it seems a bit complicated.
All the best - Wayne Riesterer
--
To post to this group, send email to javaprogrammingwithpassion@googlegroups.com
To unsubscribe from this group, send email to
javaprogrammingwithpassion+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaprogrammingwithpassion?hl=en
