I'd like to address two more issues:
As we learned back in Session 4,
An object-oriented program is a set of objects that collaborate to achieve a goal.
We sometimes use a tool like BlueJ or JUnit which gives us a way to create one or more objects and make them talk to one another. With such a tool, our only responsibility is to create the universe of objects that make up our program and then "kick" one of them to start the computation. The tool does the rest.
What is the rest? How does the Java virtual machine start a program? The answer is main(). Every Java program must have a main() method. main() is not part of an object; it's just the starting point for a program. Whenever we try to run a class using the java command, it looks for a main() method in the class that we are executing. That class must be public static void and take a String array as an argument. If java doesn't find a match, it complains. For example:
mac os x > java Association
Exception in thread "main" java.lang.NoSuchMethodError: main
BlueJ and JUnit both have a main() in the program that we run. In JUnit, the junit.XXXXui.TestRunner classes contain main() methods.
When we write our own applications, we have to write our own main() method. You can think of main() as your Big Bang -- the place and time at which we create the universe of objects that make up our program and bring one of them to life by sending it a message. That starts the computation that is our program running. (If you prefer not to use an impersonal scientific metaphor, you can think of main() as the Hand of God.)
I prefer to place my main() method in a class separate from the classes that define my objects. That reinforces the idea that main() is different from the rest of my code. The fact that we have to put main() into a class is just a feature of Java -- all code files consist of classes. (Java allows us to put a main() method into any class, as we do in our xxxTest classes.)
Another advantage to this separation is that it avoids this temptation:
public class Game
{
public static void main( String[] args )
{
System.out.println( play() );
}
public String play()
{
return "I win";
}
}
... which causes this problem:
mac os x > javac Game.java
Game.java:5: non-static method play() cannot be referenced from a static context
System.out.println( play() );
^
1 error
We haven't created a Game object to which we can send a play() message!
The lesson, at least for this course while we are learning how to write Java programs: Always put main() in a separate "driver" class. Let it create one or more objects and then send one of them a message to start the computation.
The most direct answer to the question is, "No". catch catches exceptions. But this is an excellent question that deserves a deeper answer.
Why would we want catch another condition? Because there are other exceptional cases that our code needs to handle.
Consider our Nim game. An input might be bad for one of several reasons. When we ask the user to enter a move, he may he enter a non-integer answer. That causes Integer.parseInt() to throw a NumberFormatException. We learned how to handle this situation last time.
But the user might enter an integer, just not a legal one! If he enters a 0, or a 4, then he has created an exceptional case that we need to handle. Ordinarily, we would do this with an if statement:
if ( stonesSelected < 1 )
System.out.println( "You must take at least one stone." );
But in some ways this is an excpetion just like the NumberFormatException: we want to print an error message and ask the user to try again. It's just not the sort of exception that Java already knows about.
Most of the time in Java, if Java can do something, so can we. This is possible because most of Java is implemented in the form of collaborating objects, and we can create a different object and substitute it for the Java object: We can make our own kind of Exception and throw it!
Here's how: a simple demo
... write our own Exception class ... substitutable objects
Any other questions?
Read the final version of BallWorldFrame from last time, which has a Ball paints and moves. A Ball is a Disk that knows how to move.
... discuss parts of the code that are new, confusing, ...
How do we test one of these graphical objects?