110 likes | 115 Views
Define your own exception class to distinguish your exceptions from any other kind. This implementation consists of a default constructor and a constructor that takes a simple message string as an argument.
E N D
Exceptions All Exception classes look like this! Define your own exception class to distinguish your exceptions from any other kind. public class AssertionException extends Exception { AssertionException() { super(); } AssertionException(String s) { super(s); } } The implementation consists of a default constructor, and a constructor that takes a simple message string as an argument. Both constructors call super() to ensure that the instance is properly initialized. — P2 —
Testing Assertions It is easy to add an assertion-checker to a class: private void assert(boolean assertion) throws AssertionException { if (!assertion) { throw new AssertionException("Assertion failed in LinkStack"); } } • What should an object do if an assertion does not hold? • Throw an exception. — P2 —
Make Make is a Unix and Windows-based tool for managing dependencies between files. You can specify in a “Makefile”: • Which files various targets depend on • Rules to generate each target • Macros used in the dependencies and rules • Generic rules based on filename suffixes When files are modified, make will apply the minimum set of rules to bring the targets up-to-date. — P2 —
A Typical Makefile .SUFFIXES: .class .java .java.class : # generic rule javac $< CLASS = AbstractBoardGame.class AssertionException.class \ BoardGame.class GameDriver.class Gomoku.class Player.class \ Runner.class TestDriver.class TicTacToe.class all : TicTacToe.jar Test.jar # default target TicTacToe.jar : manifest-run $(CLASS)# target and dependents jar cmf manifest-run $@ $(CLASS) # generation rule Test.jar : manifest-test $(CLASS) jar cmf manifest-test $@ $(CLASS) clean : rm -f *.class *.jar — P2 —
Running make % make javac AbstractBoardGame.java javac GameDriver.java javac TestDriver.java jar cmf manifest-run TicTacToe.jar AbstractBoardGame.class AssertionException.class BoardGame.class GameDriver.class Gomoku.class Player.class Runner.class TestDriver.class TicTacToe.class jar cmf manifest-test Test.jar AbstractBoardGame.class AssertionException.class BoardGame.class GameDriver.class Gomoku.class Player.class Runner.class TestDriver.class TicTacToe.class % touch Runner.java % make Test.jar javac Runner.java jar cmf manifest-test Test.jar AbstractBoardGame.class AssertionException.class BoardGame.class GameDriver.class Gomoku.class Player.class Runner.class TestDriver.class TicTacToe.class — P2 —
RCS command overview — P2 —
Using RCS When file is checked in, an RCS file called file,v is created in the RCS directory: mkdir RCS # create subdirectory for RCS files ci file # put file under control of RCS Working copies must be checked out and checked in. co -l file # check out (and lock) file for editing ci file # check in a modified file co file # check out a read-only copy ci -u file # check in file; leave a read-only copy ci -l file # check in file; leave a locked copy rcsdiff file # report changes between versions — P2 —
Additional RCS Features Keyword substitution • Various keyword variables are maintained by RCS: $Author$ who checked in revision (username) $Date$ date and time of check-in $Log$ description of revision (prompted during check-in) Revision numbering: • Usually each revision is numbered release.level • Level is automatically incremented upon each check-in • A new release is created explicitly: ci -r2.0 file — P2 —
Other tools Be familiar with the programming tools in your environment! • memory inspection tools: like ZoneRanger help to detect other memory management problems, such as “memory leaks” • zip and jar: store and compress files and directories into a single “zip file” • awk, sed and perl: process text files according to editing scripts/programs — P2 —
What you should know! • How do make and Ant support system building? • What functionality does a version control system support? • When should you use a debugger? • What are breakpoints? Where should you set them? • What should you do after you have fixed a bug? • When should you use a profiler? • What is an IDE? — P2 —
Can you answer these questions? • When should you use Ant rather than make? • When should you use CVS rather than RCS? • How often should you checkpoint a version of your system? • When should you specify a version of your project as a new “release”? • How can you tell when there is a bug in the compiler (rather than in your program)? • How can you tell if you have tested every part of your system? — P2 —