Presentation is loading. Please wait.

Presentation is loading. Please wait.

Week 14 - Monday.  What did we talk about last time?  Image manipulation  Inheritance.

Similar presentations


Presentation on theme: "Week 14 - Monday.  What did we talk about last time?  Image manipulation  Inheritance."— Presentation transcript:

1 Week 14 - Monday

2  What did we talk about last time?  Image manipulation  Inheritance

3

4

5

6  The Prey class now extends the Hunter class, getting everything that it had before  Then we just needed to change the update() method to run from Hunters instead of chasing Prey objects

7  To make the Hunter and Prey classes work, we now need to know if a specific object belongs to a given type  Every object has a getClass() method  We can test to see if an object’s getClass() method gives back Hunter.class or Prey.class  By doing so, we can tell the class of a given object

8  What if we create a super hunter?  Super hunters are larger and faster than hunters, and try to eat everything, including each other  We make SuperHunter extend Hunter  We call the Hunter constructor with the right speed, size, and color  Then, we change the update() method to reflect the right behavior

9

10  In this course, you have already dealt with image and audio files, but you didn't do any direct input or output to them  It is possible to read and write individual pieces of data to a file  Files are great because they exist after the program is done  Reading and writing to a file is very similar to reading and writing to the command line (using Scanner and System.out )

11  Reading from a text file is almost ridiculously easy  We use Scanner, just like reading from the command line  We just have to create a new File object that gives the file we want to read from  This code will read from some file called input.txt, as if someone were typing its contents into the command line Scanner in = new Scanner(new File("input.txt"));

12  Unfortunately, if you type that into Eclipse, you'll get a red squiggle underneath the code  The problem is this: What would happen if input.txt doesn't exist?  This is an error situation, and Java uses something called exceptions to deal with errors  You can catch an exception and do something to recover from the situation

13  However, the error if the file isn't there is called a FileNotFoundException, and it's a checked exception  If there is the possibility of throwing a checked exception, your code has to deal with it or else your program will not compile  Well, that's annoying: Now we have to learn how to deal with catching exceptions

14  You've seen exceptions before:  NullPointerException  ArrayIndexOutOfBoundsException  etc.  These are called unchecked exceptions, because you don't have to deal with them  You usually can't deal with them: They mean that you're program is messed up

15  The alternative to catching an exception is throwing it up to the next level, making it someone else's problem  Sure, your program will crash if no one deals with it, but at least your code will compile  We do this by putting a throws FileNotFoundException on the declaration of main() (or whatever method we're in) public static void main(String[] args) throws FileNotFoundException { Scanner in = new Scanner(new File("input.txt")); public static void main(String[] args) throws FileNotFoundException { Scanner in = new Scanner(new File("input.txt"));

16  Java loves objects  If you want to write to a file, you've got to create a PrintWriter object, based on a FileOutputStream object (which takes the file name as a parameter)  Once you've got a PrintWriter, you can use it just like System.out PrintWriter out = new PrintWriter(new FileOutputStream ("output.txt"));

17  Just like making a Scanner from a File, making a PrintWriter from a FileOutputStream will potentially throw a FileNotFoundException  Weird, isn't it? I mean, you don't expect to find a file when you're about to write one  Sometimes Java doesn't make sense  Anyway, adding the throws FileNotFoundException to the method declaration will still solve the problem

18  Unlike the command line, you should really close files when you're done reading from them  If you forget, it's okay: Java will automatically close them when your program quits  But, for situations where you're accessing multiple files, it may be important to close them Scanner in = new Scanner(new File("input.txt")); PrintWriter out = new PrintWriter(new FileOutputStream ("output.txt")); //do stuff in.close(); out.close(); Scanner in = new Scanner(new File("input.txt")); PrintWriter out = new PrintWriter(new FileOutputStream ("output.txt")); //do stuff in.close(); out.close();

19  Let's write a program that prompts the user for 1o int values and then writes them to a file called numbers.txt  Then, let's write another program that opens numbers.txt, reads all 10 numbers, sorts them, and prints them out in order

20

21

22  Finish file I/O  Lab 14

23  Keep working on Project 5


Download ppt "Week 14 - Monday.  What did we talk about last time?  Image manipulation  Inheritance."

Similar presentations


Ads by Google