COMP1406 Tutorial 11

Transcription

1 COMP1406 Tutorial 11 Objectives: To gain more practice handling Exceptions. To create your own Exceptions. To practice reading and writing binary files. To practice reading and writing text files. To practice reading and writing object files. To complete our DVDCollection App so that it can save and load DVDCollections to/from a file. Getting Started: Download the Tutorial 11.zip file from the CULearn website. Place the Tutorial 11.zip file somewhere that you can unzip it such as the Z drive in the labs. Select it and unzip it by selecting the file and then rightclicking and selecting Extract All from the popup menu. From the dialog box that appears, click Extract. It should by default, extract to the same folder that contains the zipped file. To open the project in IntelliJ, select Open from the File menu. Select the Tutorial 11 folder that is inside of the Tutorial 11 folder that you unzipped. MAKE SURE THAT YOU SELECT THE ONE INSIDE OF THE OTHER ONE (i.e., the inner one). The project should be loaded along with all of its original source files. Expand the project by clicking the triangle on its left. Click on the src subfolder. The code provided in this tutorial contains the solutions from Tutorial 4 which pertained to the Game that we simulated with various movable and stationary objects such as Player, Ball, Trap, Wall and Prize. It also contains the completed code from Tutorial 3 which pertained to Customer, Store and Mall classes. We will make use of these throughout this tutorial. Tutorial Problems: 1) Recall these classes GameObject MovableObject Player Ball StationaryObject Wall Trap Prize Game GameTestProgram GameBoard GameBoardTestProgram 1

2 Now we will add code that will generate a CollisionException when a Player collides with a wall. Of course, your code should attempt to prevent the Player from colliding with a wall, but in the off-chance that there is a bug in your code or that something unexpected occurs in the game, your player may end up colliding with the wall. Create and compile a CollisionException class as follows: public class CollisionException extends Exception { public CollisionException() { super("player collided with wall!"); Note that any new exceptions that you define must extend the Exception class or one of its subclasses. Once this code is saved and compiled, you are able to generate such an exception. Copy and then complete the code (i.e., it is not finished so you have to write it) for the following method in the Wall class: public boolean contains(point2d p) { // return true if p.x is in the range from "this.location.x to // (this.location.x+this.width-1)" and if p.y is in the range from // "this.location.y to (this.location.y+this.height-1)" // otherwise return false Add the following methods to the Game class so that we can get the Players and the Walls from the Game: public ArrayList<Player> getplayers() { ArrayList<Player> result = new ArrayList<Player>(); for (GameObject g: gameobjects) { if (g instanceof Player) result.add((player)g); return result; public ArrayList<Wall> getwalls() { ArrayList<Wall> result = new ArrayList<Wall>(); for (GameObject g: gameobjects) { if (g instanceof Wall) result.add((wall)g); return result; Append the following piece of code to the end of the updateobjects() method in the Game class which will compare all players with all walls to see if a collision occurs and will then throw our newly defined exception if it has indeed occurred: ArrayList<Player> ArrayList<Wall> players = getplayers(); walls = getwalls(); for (Wall w: walls) { for (Player p: players) { if (w.contains(p.location)) throw new CollisionException(); 2

3 The code will no longer compile. You should see an error stating: Unhandled exception: CollisionException. JAVA is telling us that we need to tell everyone that this updateobjects() method may now generate a CollisionException. Add an appropriate throws clause to the method definition as follows and then re-compile: public void updateobjects() throws CollisionException { The GameTestProgram and GameBoardTestProgram will both generate the same compile error because we are calling the updateobjects() method from here and we now must decide what to do when the exception is generated. For now, we are not sure what to do and we just want to see if we can generate our exception. So, to simply satisfy the compiler for now, add throws CollisionException to the main methods as follows, and then re-compile: public static void main(string args[]) throws CollisionException { Run the GameTestProgram. You should see the exception generated as follows (although your code's line numbers may differ): Exception in thread "main" CollisionException: Player collided with wall! at Game.updateObjects(Game.java:43) at GameTestProgram.main(GameTestProgram.java:53) at com.intellij.rt.execution.application.appmain.main(appmain.java:144) Congratulations you have just thrown a brand new exception. Notice that it occurs right where we threw it from the updateobjects() method in the Game class. Run the GameBoardTestProgram. You should see the exception occur just before the Player collides with the wall above him/her: #################### # $ # # # # # ########### # # ##### $ # # ^ # # # # # # # # # # # O# # $ # # # #################### Exception in thread "main" CollisionException: Player collided with wall! at Game.updateObjects(Game.java:43) at GameBoardTestProgram.main(GameBoardTestProgram.java:40) at com.intellij.rt.execution.application.appmain.main(appmain.java:144) 2) Now we need to catch and handle our exception properly. First, let us catch it. But where do we catch it? Recall that we have added some throws clauses to our methods and eventually the main method threw the exception and the Java Virtual Machine caught it, and hence stopped the program. 3

4 Change the following code from the main method in GameBoardTestProgram: into this: for (int i=0; i<15; i++) { g.updateobjects(); g.displayboard(); System.out.println(" "); for (int i=0; i<15; i++) { g.displayboard(); System.out.println(" "); g.updateobjects(); catch (CollisionException e) { // do nothing Remove the throws CollisionException clause that we added from the main method's definition and then re-run the code. Your program should run to completion because we caught the exception and ignored it. Let's see how many times the exception actually occurred. Add the following line inside the catch block, then re-run the code again: e.printstacktrace(); Scroll through the program output. Did you see how many times the exception occurred? I think you will notice it occurred 2 times, so the Player hit 2 walls as it moved (because the player does not stop when it hits the walls, it goes right through them). Obviously in a real game this would be serious. For now, let us simply stop the player when it hits a wall. We do this by setting its speed to 0. So we need to add the following to the catch block instead of printing the stack trace: System.out.println("*** " + e.getmessage() + " setting speed to 0"); player.speed = 0; Re-run the code. Notice that the player no longer goes through the wall. You may also notice that the exception occurs a LOT more now! What is going on? Do you understand? Print out the player's location from within the catch block. Think about it. Ask the TA if you do not understand why the exception occurs a lot now. 3) There are some bad things about the code. First of all, we are catching the exception in the wrong spot. Notice that our catch block "assumes" that it was the Player object stored in the player variable that collided because it sets that player's speed to 0. However, if any other Player collided with a wall, we would be setting the speed of the wrong Player. Can we fix this? Yes. There are many ways to accomplish this. One interesting way is to allow the CollisionException to store the Player that caused it. Then we can access this from our catch block. Looking to the future, we may wish to do something similar for Ball objects and perhaps any MovableObject. So let's allow any MovableObject to be a cause of the exception. Add an attribute (i.e., instance variable) to the CollisionException class: MovableObject source; 4

5 Then allow this to be set by the constructor by changing it as follows: public CollisionException(MovableObject s) { super(s + " collided with wall!"); source = s; Go back to the updateobjects() method in the Game class and pass in (to the call to the CollisionException constructor) the Player who generated the exception. Finally, in the catch block of the GameBoardTestProgram, replace player with e.source. The code should compile and still run. It seems that we did not do much, but we did clean up the code and allow the exception to keep track of any MovableObject that collides. 4) Let's eliminate the problem that caused the exception to occur so many times. Hopefully by now you realize that the exception kept occurring because the player was "stuck" on the wall. You will have to somehow "undo" the player's last forward movement. Since we are already keeping track of the previouslocation of the player, we can simply restore it when a collision occurs. Make the appropriate changes and then re-run your GameBoardTestProgram to make sure that the exception occurs only once. The exception message should appear after the 6th board is displayed not after the last displayed board as before. 5) We will now switch over to our Customer/Store example. Run the StoreTestProgram to make sure that it works. Also, create, save and compile the following test program: public class CustomerTestProgram { public static void main(string args[]) { Customer c1 = new Customer("Amie", 14, 'F', 100); Customer c2 = new Customer("Brad", 15, 'M', 0); Recall that we can create a DataOutputStream that allows us to output primitive types to a file as follows: DataOutputStream out = new DataOutputStream(new FileOutputStream("customer1.txt")); out.writeutf(c1.getname()); // UTF is short for "Unicode Text Format" out.writeint(c1.getage()); out.close(); Add such code to the CustomerTestProgram so that the first customer Amie is saved to a file called customer1.txt and Brad is saved to a file called customer2.txt. You will need to write all 5 attributes for each person. This will require you to add a getmoney() method in the Customer class. You will need to import java.io.*; and don't forget to close the files when you are done using the close() method. The code that you write, may not compile likely, you will get some errors indicating that you need to handle java.io.filenotfoundexception and java.io.ioexception. Recall that we can handle these using try/catch blocks. Place your file-related code in a try block and catch the exceptions, doing nothing for now when they are caught: // Write your code here catch (FileNotFoundException e) { catch (IOException e) { 5

6 Run your code now. Once it has completed, you should see two files appear in the left side of the IDE just below the src folder called customer1.txt and customer2.txt. If you open these files, you will notice that they each look weird like this: Amie FB BradM6 The files look weird because the information is stored as binary. As it turns out, when you open up binary information in a text editor (like notepad), the only information that will appear somewhat normal are Strings and chars since their byte values correspond to values that the text editor understands to be text. If we want to save many Customer objects to a file, we would need to duplicate the 5 or 6 lines of code that do the saving. It could be very wasteful. Instead of doing this in our test code, it is more efficient to make a Customer method to do this. Create the following method in the Customer class (you will need to import the two file-related classes from the java.io package): public void saveto(dataoutputstream afile) throws IOException { Copy the code that does the writing of the Customer's information into this method. Note that you won't use variables c1 and c2 now but you can replace it with the keyword this or even better you can access the 5 instance variables directly now instead of using the get methods. Make sure NOT to open nor close the file in this method, that is the responsibility of the method that called this one. Assume that the DataOutputStream has already been created and was passed in. As a result, the try block of our test code should now look like this make the appropriate changes: DataOutputStream out; out = new DataOutputStream(new FileOutputStream("customer1.txt")); c1.saveto(out); out.close(); out = new DataOutputStream(new FileOutputStream("customer2.txt")); c2.saveto(out); out.close(); catch (FileNotFoundException e) { catch (IOException e) { Re-run the CustomerTestProgram. It should still work. The code is shorter now and more efficient. How do we read the Customers back in again? Well, we can simply use a DataInputStream instead. This time, we'll make a static method so that we don't need to have a Customer already in order to load one from a file. Create the following static method in the Customer class: public static Customer readfrom(datainputstream afile) throws IOException { 6

7 Complete the method so that a Customer object is created and returned from the method. The code should make use of the DataInputStream's readutf(), readint(), readchar() and readfloat() methods to read and set the data for the customer. Test your code by adding the following to the end of the CustomerTestProgram and running it. You should see the correct values displayed that correspond to the original customer's data. DataInputStream in; in = new DataInputStream(new FileInputStream("customer1.txt")); System.out.println(c1.readFrom(in)); in.close(); in = new DataInputStream(new FileInputStream("customer2.txt")); System.out.println(c1.readFrom(in)); in.close(); catch (FileNotFoundException e) { catch (IOException e) { 6) Now we will save multiple customers to a common store.txt file. Write the following similar method in the Store class: public void saveto(dataoutputstream afile) throws IOException { Complete this method so that it loops through the Customer objects and saves each one of them to the file. Make sure that you call your saveto() method in the Customer class for each customer. Test your code by adding the following to the end of the StoreTestProgram file's main method: DataOutputStream out = new DataOutputStream(new FileOutputStream("store.txt")); walmart.saveto(out); out.close(); catch (FileNotFoundException e) { catch (IOException e) { Look at the resulting store.txt file. Did it work? Go to the Store class and write method below to read in the customers again. Notice that the code to actually read in the Customer object's data is missing. Write this code using the readfrom() method that you wrote in the Customer class. public static Store readfrom(datainputstream afile) throws IOException { Store s = new Store("?"); while (afile.available() > 0) { // Now read in a customer from the file and add him/her to the store return s; Test your code by adding the following to the end of the StoreTestProgram file's main method: DataInputStream in = new DataInputStream(new FileInputStream("store.txt")); walmart = Store.readFrom(in); in.close(); catch (FileNotFoundException e) { 7

8 catch (IOException e) { System.out.println("\n\nHere are the customers from the file's Store object:"); walmart.listcustomers(); Run the test code. If your code was written properly, you should see the customers with names beginning from A to Z listed twice the first list represents data from the original object and the second list represents data that was read in from the file. The two lists should be identical. 7) Now although we can save and load the Store as well as Customers, it would be nice to save everything as text so that we can browse through it with a text editor. Let's do this now. Go through all of your code in Store, Customer, and StoreTestProgram and do the following: Amie 14 F Brad 15 M 0.0 i. replace DataOutputStream and FileOutputStream with PrintWriter and FileWriter, respectively. ii. replace DataInputStream and FileInputStream with BufferedReader and FileReader, respectively. iii. replace all of the writexxx() code with println(). iv. replace all of the readxxx() code with readline(). You will need to convert the incoming age, gender and money strings into int, char and float types. Do you remember how to do this? We can say Integer.parseInt(aString) to an incoming string to convert it to an int. A similar approach can be used for floats. For chars, we simply do a charat(0) to get the first char of the incoming string. v. There is no method called available() for BufferedReader objects. Instead, there is a method called ready() which returns a boolean indicating whether or not the buffer is able to be read. So, replace afile.available() > 0 with afile.ready(). Run the StoreTestProgram it should work as before. However, open up the store.txt file to see what it looks like. It should look like this: Amie 14 F Brad 15 M 0.0 Cory 10 M Dave Modify your code so that a blank line separates the customers in the file as shown below. Make sure that your code still reads in the data properly: 8

9 Cory 10 M Dave 8) Now see if you can save the customers into the store.txt file (and read them back in again) with this file format: ,Amie,14,F, ,Brad,15,M, ,Cory,10,M, ,Dave,5,M,48.0 To read it in again, you will want to use the split() method from the String class. Recall an example of how to use it: String s1 = "Mark,Lanthier,48,M,false"; String[] tokens = s1.split(","); for(string token: tokens) System.out.println(token); The code above will produce the following output: Mark Lanthier 48 M false Test your code by re-writing the file using the StoreTestProgram, viewing the store.txt file to make sure that it saved in the correct format, and was able to be read in again. MORE CHALLENGING QUESTIONS: 9) Let's alter the code so that Ball objects also collide. Start by renaming the getplayers() method in the Game class to getmovableobjects() and making sure that it returns an ArrayList<MovableObject> of all objects that are instances of MovableObject. (i.e., just change "Player" everywhere to "MovableObject"). You will have to change the updateobjects() method accordingly to use this new method. Make sure that the Game class compiles before moving on. Run the code in the GameBoardTestProgram. You should notice that the ball stops in front of the wall to its right. However, there was no collision. The ball just happened to slow down and stop. So, no CollisionExceptions were generated for the ball. Try increasing the speed of the ball to 6 in the GameBoardTestProgram and then run the code again. You will notice that no exception was generated for the ball and that it went beyond the wall. What's up with that? Do you understand? Plot the ball's course and watch the speed (and location) as it slows down: 9

10 Notice how the ball "skipped over" the wall. Because the ball's speed causes it to move multiple grid locations at one, it can "skip over" certain locations in the grid, which may or may not contain walls. We did not notice this problem with the player because it was moving at speed 1, but if the player was to move faster, it would have the same problem. How can we check for collisions at this speed? Do you have any ideas? To check for collisions, we could check ALL the locations in between the last location and the current desired location to make sure that there were no walls along the way. Change the updateobjects() method in the Game class to check all of the locations between the MovableObject's last location and current location. Keep your code simply by assuming that MovableObjects always move either up, down, left or right never at any other angle. Re-compile your code and make sure that the ball collides properly. You should see exactly 2 collisions one for the Player and one for the Ball: #################### # $ # # # # # ########### # # ##### $ # # ^ # # # # # # # # # # # o# # $ # # # #################### Adjust the code so that when a Ball collides, it changes direction (i.e., bounces away). It's tricky. Start perhaps by simply negating the speed. Test your code. Try changing the ball's speed to 8 and then to 2. For speed of 2, go to the ball's moveforward() method and adjust it so that the ball does not slow down. 10) Let us save and then load the Store as an object (as opposed to binary and text as we have done). Recall that to save as whole objects, we simply need to implement the Serializable interface. Add implements java.io.serializable to your class definitions of Customer and Store. Add the following to the bottom of your StoreTestProgram so that it saves the Store using an ObjectOutputStream using the following lines: ObjectOutputStream objout; objout = new ObjectOutputStream(new FileOutputStream("store2.txt")); objout.writeobject(walmart); objout.close(); 10

11 catch(ioexception e) { You DO NOT need to add any methods in the Customer or Store classes! Just re-run the test program. Look at the store2.txt file produced. It looks a little weird. In fact, it is a binary format which contains information about the class. Add the following to the bottom of your StoreTestProgram so that it reads in the Store using an ObjectInputStream using the following lines: walmart = new Store("Walmart"); ObjectInputStream objin; objin = new ObjectInputStream(new FileInputStream("store2.txt")); walmart = (Store)objIn.readObject(); objin.close(); catch(ioexception e) { System.out.println("Here are the customers from the file's Store object:\n"); walmart.listcustomers(); The compiler will complain that you need to also now catch a ClassNotFoundException. That is because JAVA will try to reconstruct the Store objects itself upon reading it from the file and there may be problems creating objects if the file is corrupt, for example. You will need to add another catch block to catch this error. Now recompile and run the code. Ok so it does not seem very impressive does it? Let's look at how powerful this object saving/loading actually is. Go to your Customer and Store classes and comment out the saveto() and readfrom() methods. Also, comment out the try/catch blocks in your CustomerTestProgram and StoreTestProgram that were from our PrintWriter and BufferedReader testing. Run the code. Your code will STILL work!! That is because these methods are no longer used, of course. So, when writing whole objects to a file, you do not need to do anything more that simply implement the Serializable interface. The readobject() and writeobject() methods are available for free! Now do you see the benefits? Everything is not as "peachy" as it sounds though. Go to the Customer class and change the money variable to a double instead of float. Change the getmoney() method to return a double instead of float. Now go to the StoreTestProgram and comment out the first try/catch block that saves the object to a file. There should only be one try block remaining in the test code. Run the code. It should run ok, but in fact, there was a problem. In the catch block for the IOException, add this line, then re-compile and run again : System.out.println(e.getMessage()); In the output you should notice that the following error is displayed: Customer; local class incompatible: stream classdesc serialversionuid = , local class serialversionuid = The Store object is unable to be read in now!! As it turns out, the way the Customer and Store objects are stored in the file is dependent on the class definition itself. Since we changed the Customer class definition, we can no longer read in the store.txt file which is based on the previous version of the Customer class. JAVA "stamps" each class with an ID called a serialversionuid. This changes each time the class is modified in some way such as modifying or deleting instance variables and other methods etc 11

12 Now uncomment the 2nd last try/catch block in the StoreTestProgram so that the store2.txt file is rewritten to the file using the new Customer class definition. The program should now be able to read it back in again without problems. Try it. Do you see the disadvantage of using ObjectStreams? Once you save the data, you need to keep the classes unchanged if you want to be able to read it back in. Of course, it is easiest to keep a copy of the code that was able to read the object back in. Later you can write programs that read it in and convert it to the new format. But it can really be a hassle. So, be aware of these issues when saving as objects. 11) Get your code from Tutorial 9 which represented the DVDCollection GUI that allowed you to sort the DVD objects. Add Save and Load menu options to the File menu. Complete the code so that various DVDCollections can be saved and loaded from a file using either a binary or text-based format. Use the FileChooser dialog box (see chapter 7 of the notes) to allow the user to pick the file name to save and load. Test your code to make sure that it works. REMINDERS: Don't forget to save all of your work on a USB drive, or it to yourself. Make sure to complete the tutorial at home, as it will give you extra practice. 12