Software Engineering for Students A Programming Approach

Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach

web.firat.edu.tr
from web.firat.edu.tr More from this publisher
21.08.2013 Views

SELF-TEST QUESTION 17.5 Exceptions and exception handlers 245 17.6 You are driving in your car when you get a flat tire. You change the tire and continue. What strategy are you adopting – forward or backward error recovery? Now that we have identified two strategies for error recovery, we return to our analysis of the two main types of error. Anticipated faults can be analyzed and predicted. Their effects are known and treatment can be planned in detail. Therefore forward error recovery is not only possible but most appropriate. On the other hand, the effects of unanticipated faults are largely unpredictable and therefore backward error recovery is probably the only possible technique. But we shall also see how a forward error recovery scheme can be used to cope with design faults. 17.5 ● Exceptions and exception handlers We have already seen that we can define a class of faults that arise only occasionally, but are easily predicted. The trouble with occasional error situations is that, once detected, it is sometimes difficult to cope with them in an organized way. Suppose, for example, we want a user to enter a number, an integer, into a text field, see Figure 17.1. The number represents an age, which the program uses to see whether the person can vote or note. First, we look at a fragment of this Java program without exception handling. When a number has been entered into the text field, the event causes a method called actionPerformed to be called. This method extracts the text from the text field called ageField by calling the library method getText. It then calls the library function parseInt to convert the text into an integer and places it in the integer variable age. Finally the value of age is tested and the appropriate message displayed: Figure 17.1 Program showing normal behavior

246 Chapter 17 ■ Software robustness > > public void actionPerformed(ActionEvent event) { String string = ageField.getText(); age = Integer.parseInt(string); if (age > 18) response.setText("you can vote"); else response.setText("you cannot vote"); } This piece of program, as written, provides no exception handling. It assumes that nothing will go wrong. So if the user enters something that is not a valid integer, method parseInt will fail. In this eventuality, the program needs to display an error message and solicit new data, (see Figure 17.2). To the programmer, checking for erroneous data is additional work, a nuisance, that detracts from the central purpose of the program. For the user of the program, however, it is important that the program carries out vigilant checking of the data and when appropriate displays an informative error message and clear instructions as to how to proceed. What exception handling allows the programmer to do is to show clearly what is normal processing and what is exceptional processing. Here is the same piece of program, but now written using exception handling. In the terminology of exception handling, the program first makes a try to carry out some action. If something goes wrong, an exception is thrown by a piece of program that detects an error. Next the program catches the exception and deals with it. public void actionPerformed(ActionEvent event) { String string = ageField.getText(); try { age = Integer.parseInt(string); } catch (NumberFormatException e){ response.setText("error. Please re-enter number"); return; } if (age > 18) response.setText("you can vote"); else response.setText("you cannot vote"); } In the example, the program carries out a try operation, enclosing the section of program that is being attempted. Should the method parseInt detect an error, it throws a NumberFormatException exception. When this happens, the section of program enclosed by the catch keyword is executed. As shown, this displays an error message to the user of the program. > >

SELF-TEST QUESTION<br />

17.5 Exceptions and exception handlers 245<br />

17.6 You are driving in your car when you get a flat tire. You change the tire<br />

and continue. What strategy are you adopting – <strong>for</strong>ward or backward<br />

error recovery?<br />

Now that we have identified two strategies <strong>for</strong> error recovery, we return to our analysis<br />

of the two main types of error. Anticipated faults can be analyzed and predicted.<br />

Their effects are known and treatment can be planned in detail. There<strong>for</strong>e <strong>for</strong>ward<br />

error recovery is not only possible but most appropriate. On the other hand, the effects<br />

of unanticipated faults are largely unpredictable and there<strong>for</strong>e backward error recovery<br />

is probably the only possible technique. But we shall also see how a <strong>for</strong>ward error recovery<br />

scheme can be used to cope with design faults.<br />

17.5 ● Exceptions and exception handlers<br />

We have already seen that we can define a class of faults that arise only occasionally,<br />

but are easily predicted. The trouble with occasional error situations is that, once<br />

detected, it is sometimes difficult to cope with them in an organized way. Suppose,<br />

<strong>for</strong> example, we want a user to enter a number, an integer, into a text field, see<br />

Figure 17.1.<br />

The number represents an age, which the program uses to see whether the person<br />

can vote or note. First, we look at a fragment of this Java program without exception<br />

handling. When a number has been entered into the text field, the event causes a<br />

method called actionPer<strong>for</strong>med to be called. This method extracts the text from<br />

the text field called ageField by calling the library method getText. It then calls<br />

the library function parseInt to convert the text into an integer and places it in the<br />

integer variable age. Finally the value of age is tested and the appropriate message<br />

displayed:<br />

Figure 17.1 Program showing normal behavior

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!