• No results found

When it does not work

In document Java (Page 69-73)

What do you do when a Java program goes wrong? There are three case 1. It won't compile. This is easy to fix.

2. It compiles and runs, but crashes. In Java this will involve 'thowing an exception'. This is fairly easy to fix.

3. It compiles and runs, but does the wrong thing, or outputs the wrong result. This is a problem.

We will look at each case Compile error

These are easy to fix, because the compiler will tell you the line where the error is, and some clue as to what the error is. In NetBeans and Eclipse, the IDE will flag the error with an ugly red line before you run it. For example in NetBeans:

The light bulbs at lines 9 and 10 mean information. The red exclamation marks mean an error. The red wavy line under d means there is some problem with it.

Hover the mouse over the information, and it tells you the error message:

Run-time exception

The first version of Java was developed for the software in TV remotes. If a TV remote crashes, the user is going to be quite annoyed. So Java was developed to handle run-time errors in a controlled way.

These events are called exceptions. For example:

There is no red waviness so no compile-time errors. But when we run it:

we get an exception. Read the message carefully. The type of exception is

java.lang.ArithmeticException. So its something to do with arithmetic. / by zero is divide by zero.

Then it tells us where - at Main.main - in other words, in the method called main, in the class called Main. And Main.java:8 means it is at line 8 in the file called Main.java. Pretty easy to fix.

In practice exception messages are a lot more tricky to read than this. Here we just have one method, called main. What often happens is that we have one method which uses another, which uses another, which uses another, maybe to a depth of ten, and the exception occurs at the tenth level, causing one at the ninth, and so on, each of which are reported. So many of the exceptions are not in code you have written. But you have caused it, indirectly. Look towards the top at files you have written, and look in them at the line numbers indicated.

Incorrect programs

In formal software development, you start with a specification - a statement of what the program should do, in terms of possible input and required output. A program which performs according to this specification is correct. Otherwise its incorrect.

In other words the program runs, but it does the wrong thing and produces the wrong output. This is hard to fix. In effect it is a detective novel, a whodunnit, and you have to find the guilty party.

Usually this is done by a combination of hunch and logical deduction.

Here are some suggestions

1. One piece of evidence is the output - what it actually does. Can you make sense of that? How could the actual output have been caused?

2. Can you work out which piece of code is causing the error? You should write and test code in very short pieces. Do not write code like an essay, 2000 words at a time. Write at most 10 lines, and test it. This means you can be fairly confident (does not always work) that what you have written is correct. Or if it goes wrong, look in the last ten lines you have written.

If you have written 2000 lines of code since you last tested it, the bug is anywhere in those 2000 lines. You might as well start again, this time 10 lines at a time.

3. Use comment debugging. This means enclosing some lines of code in comments. If you still get the error, those lines are correct, and you can uncomment them. This avoids deleting and re-writing correct code.

4. Use print debugging. Use System.out.println to output the value of a variable in suspicious code.

Do you get the value you think it should be? The prize is when you find an incorrect value. You can then work backwards from there - how could it have got that value? You are close to the solution.

5. Check the algorithm. Is the method of solution actually correct? This might involve paper and pencil calculation. Chose an easy case.

6. Use a debugger. IDEs usually have a built-in debugger, which lets you step through the code one statement at a time, and set up 'watch variables' so you can see the values they take on step by step.

You also have options like 'run to cursor', 'step into' and 'step over'. Because it takes time to set the debugger up, avoid this if possible. Sometimes it isn't possible.

OOP

Java is an OOP language - it uses object-oriented programming. This is a different approach to programming from structured programming. The code we have seen up till now has not been typical Java.

This section introduces the key ideas of class and object.

It provides some examples of using common Java classes

In document Java (Page 69-73)