Software Engineering for Computer Games

1
Software Engineering for Computer Games

• Defensive programming

2
Defensive programming

• Inspired by defensive driving
• You should drive your car so as to protect
  yourself from other drivers' lack of skill, care,
  common sense, etc. After all, you can never be
  sure about what the other drivers are going to do.

3
Defensive programming

• Your classes should be prepared for the
  misbehaviour of other classes
• Your routines should be prepared for the
  misbehaviour of other routines

4
Protecting from invalid inputs

• Garbage in, garbage out is no good!
• A good program never puts out garbage, regardless
  of what it takes in.

5
Protecting from invalid inputs

• Check the values of all data from external
  sources
• Check the values of all routine input parameters
• Decide how to handle bad inputs

6
Assertions

• Protective tests usually included in code during
  development and maintenance, but removed from
  production code
• Java assert ltboolean testgt ltmessagegt
• C ASSERT(ltboolean testgt)

7
Assertions

• Assertions are like an executable documentation
  they do not make the code work, but they can
  document, more actively than comments,
  assumptions used in the program
• Java example assert denom ! 0 denom found
  to be 0.

8
Assertions

• Use error-handling code for conditions you expect
  to occur use assertions for conditions that
  should never occur
• Avoid putting executable code into assertions
• Use assertions to document and verify
  preconditions and postconditions

9
Assertions

• For highly robust code, assert and then handle
  the error anywayPlanned redundancy,
  particularly useful for very large projects,
  involving large (and not necessarily stable)
  teams and spanning over large periods of time
  (e.g. more than 106 lines, more than 100 people,
  more than 5 years)

10
Error-handling alternatives

• Return a neutral value (e.g. 0 for numeric
  computations)
• Substitute the next piece of valid data (e.g.
  when monitoring data from a device, if you get
  corrupted data then wait for the next reading)
• Return the same answer as the previous time

11
Error-handling alternatives

• Substitute the closest legal value
• Log a warning message to a file (e.g. in
  conjunction with any of the other options)
• Return an error code
• Call a centralised error-processing
  routine/object (but beware of malicious attack!)

12
Error-handling alternatives

• Display an error message wherever the error is
  encountered (but be careful not to annoy the
  user, not to spread user interface code through
  the system, and beware of being too informative
  to hackers)
• Handle the error in whatever way works best
  locally (but avoid spreading UI code through the
  system)
• Shut down

13
Error-handling

• Robustness or correctness?
• Robust always try to do something to keep system
  running, even if it leads sometimes to
  innacuracies
• Appropriate for consumer applications, e.g. a
  word processor
• Correct never return an innacurate result. No
  result is better than an innacurate result
• Appropriate for safety-critical applications,
  e.g. a nuclear reactor controller

14
Exceptions

• Use exceptions to notify other parts of the
  program about errors that should not be ignored
• Throw an exception only for conditions that are
  truly exceptional
• Do not use an exception if you can handle the
  error locally

15
Exceptions

• Throw exceptions at the right level of
  abstraction
• Include in the exception message all information
  that led to the exception
• Avoid empty catch blocks
• Consider building a centralised exception
  reporter
• Standardise your project's use of exceptions

16
Barricades

• Some classes should be allowed to work inside a
  sterilised surgical room. A barricade is a
  collection of classes that permit this

Untrusted data (GUI, external files, data feed,
etc.) error handling
Protected internal classes assertions
Barricade cleaning-up classes
17
Final remarks

• How much defensive programming should be passed
  from development code to production code?
• Leave in code that checks for important errors
• Remove code that checks for trivial errors
• Remove code that results in hard crashes
• It is a good policy to give users some time to
  save ongoing work before shutting down

18
Final remarks

• How much defensive programming should be passed
  from development code to production code?
• Leave in code that helps the program crash
  gracefully
• Log errors for your technical support personnel
• Make sure that the error messages you leave in
  are friendly

19
Final remarks

• How much defensive programming should be passed
  from development code to production code?
• Did everyone notice the bottom line?Development
  code and production code are different pieces of
  code!