Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
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. > >
- Page 217 and 218: 194 Chapter 14 ■ The basics In a
- Page 219 and 220: 196 Chapter 14 ■ The basics > str
- Page 221 and 222: 198 Chapter 14 ■ The basics Answe
- Page 223 and 224: CHAPTER 15 Object-oriented programm
- Page 225 and 226: 202 Chapter 15 ■ Object-oriented
- Page 227 and 228: 204 Chapter 15 ■ Object-oriented
- Page 229 and 230: 206 Chapter 15 ■ Object-oriented
- Page 231 and 232: 208 Chapter 15 ■ Object-oriented
- Page 233 and 234: 210 Chapter 15 ■ Object-oriented
- Page 235 and 236: 212 Chapter 15 ■ Object-oriented
- Page 237 and 238: 214 Chapter 15 ■ Object-oriented
- Page 239 and 240: 216 Chapter 15 ■ Object-oriented
- Page 241 and 242: 218 Chapter 15 ■ Object-oriented
- Page 243 and 244: 220 Chapter 15 ■ Object-oriented
- Page 245 and 246: 222 Chapter 16 ■ Programming in t
- Page 247 and 248: 224 Chapter 16 ■ Programming in t
- Page 249 and 250: 226 Chapter 16 ■ Programming in t
- Page 251 and 252: 228 Chapter 16 ■ Programming in t
- Page 253 and 254: 230 Chapter 16 ■ Programming in t
- Page 255 and 256: 232 Chapter 16 ■ Programming in t
- Page 257 and 258: 234 Chapter 16 ■ Programming in t
- Page 259 and 260: 236 Chapter 16 ■ Programming in t
- Page 261 and 262: 238 Chapter 17 ■ Software robustn
- Page 263 and 264: 240 Chapter 17 ■ Software robustn
- Page 265 and 266: 242 Chapter 17 ■ Software robustn
- Page 267: 244 Chapter 17 ■ Software robustn
- Page 271 and 272: 248 Chapter 17 ■ Software robustn
- Page 273 and 274: 250 Chapter 17 ■ Software robustn
- Page 275 and 276: 252 Chapter 17 ■ Software robustn
- Page 277 and 278: 254 Chapter 17 ■ Software robustn
- Page 279 and 280: 256 Chapter 17 ■ Software robustn
- Page 281 and 282: 258 Chapter 17 ■ Software robustn
- Page 283 and 284: 260 Chapter 18 ■ Scripting GNU/Li
- Page 285 and 286: 262 Chapter 18 ■ Scripting In sum
- Page 288: PART D VERIFICATION
- Page 291 and 292: 268 Chapter 19 ■ Testing We begin
- Page 293 and 294: 270 Chapter 19 ■ Testing within a
- Page 295 and 296: 272 Chapter 19 ■ Testing Test num
- Page 297 and 298: 274 Chapter 19 ■ Testing if (a >=
- Page 299 and 300: 276 Chapter 19 ■ Testing 3. apply
- Page 301 and 302: 278 Chapter 19 ■ Testing made con
- Page 303 and 304: 280 Chapter 19 ■ Testing 19.3 Dev
- Page 305 and 306: 282 Chapter 19 ■ Testing 19.2 The
- Page 307 and 308: 284 Chapter 20 ■ Groups The term
- Page 309 and 310: 286 Chapter 20 ■ Groups Of course
- Page 311 and 312: 288 Chapter 20 ■ Groups • Exerc
- Page 314 and 315: CHAPTER 21 This chapter explains: 2
- Page 316 and 317: Stage Input Output 21.3 Feedback be
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