Response to Undesired Events in Software Systems

1
Response to Undesired Events in Software Systems

• Kimberly Hanks and Phil Varner
• A Presentation brought to
• you by David Parnas

2
Undesired ! Unexpected

• Undesired Events are
• Deviation from the ideal operation of the system
• Not always correctable like errors
• A fact of life we have to deal with
• Correct programs, in the sense that would make
  UE handling unnecessary, do not exist

3
UE Handling Overview

• Problem Even with "correct" programs, UEs at
  runtime will occur
• To deal with them , we need to
• Know what to look for
• Successfully diagnose
• Recover if possible
• This paper proposes how

4
Problems with Perfect World

• Everyone makes errors
• Machines fail, causing programs/data to fail
• Programs change, new errors pop up
• Incorrect or inconsistent data may be supplied

5
Where Do We Start?

• Parnas assumes systems that are structured
  according to good information hiding and the
  uses hierarchy
• This shapes all of his proposals
• In particular, UE detection and handling is
  predicated on a system of levels

6
Levels of Detection and Handling

• The first clue that something is wrong can appear
  at a level other than where an UE originates
• Example
• Initiate a read on a storage resource, e.g., a
  tape block, which turns out to be bad
• Detection occurs at the HW level when the read
  cant be completed, even though initiated from
  some high-level application

7
Levels(2)

• Should the HW be responsible for a recovery
  attempt?
• Parnas says nobut where should it be handled?
• At the originating level
• Why?

8
Levels(3)

• The originating level is where the knowledge is
• The failed read happens at the HW level, but the
  HW doesnt know any useful implications
• The level where the read was initiated sits on a
  VM that provides certain abstractions to the user
• The UE is only meaningful in the context of these
  abstractions

9
Levels(4)

• What would meaningful handling look like?
• A diagnostic stated in the abstractions of the
  level
• A provision of an alternative, in the context of
  those abstractions

10
UE Handlers and Info Hiding

• We want to handle the UE at the level at which it
  is meaningful, but
• This doesnt necessarily mean the information
  necessary to handle it is available (it may have
  been abstracted away to effect good information
  hiding)
• How should we manage this tradeoff?

11
UE Handlers and Info Hiding (2)

• Everything should be made as simple as possible,
  but not simpler. Einstein
• Hide all and only information which is not likely
  to be useful in diagnosing and recovering from
  UEs
• Prediction is the key

12
Meta-structure

• The general policy proposed constitutes a
  meta-structure of UE handling
• It has several advantages
• Handlers dont violate info-hiding
• Uses hierarchy is intact
• Allows refinement without major revision
• Aids debugging

13
Separation of Case and EH/R

• Separation of Normal Case and Error
  Handling/Recovery
• Java try catch

14
Suggestion 1

• Assign responsibility for the detection of
  attempts to violate its specification to the
  "abstract machine
• trap metaphor - hide detection mechanism, expose
  interface for handling UEs
• should be able to handle errors in context of VM
  abstraction

15
Degrees of Recovery

• Hardware - handle or crash
• Instead, design for multi-level recovery
• Policy determined by cost and aim

16
No Recovery

• local
• attempts INTEGER
• do
• if attempts lt Max_attempts then
• last_character low_level_read_function (f)
• else
• failed True
• end
• end

17
Simple Recovery

• local
• attempts INTEGER
• do
• if attempts lt Max_attempts then
• last_character low_level_read_function (f)
• else
• failed True
• end
• rescue
• attempts attempts 1
• retry
• end

18
Degrees of Recovery

• local
• attempts INTEGER
• do
• if attempts lt Max_attempts then
• last_character low_level_read_function(f)
• else
• failed True
• end

rescue attempts attempts 1 if attempts
1 retry elseif attempts 2
sleep(2) retry elseif attempts 3
flush_buffers sleep(4) retry else
end end
19
Suggestion 2

• Do not specify a module to have properties which
  UEs will frequently violate
• Examples
• dont use limited cap data structures when of
  objects is unknown, etc.
• dont allow possibility of, e.g. calling pop() on
  empty stack

20
Error Indication

• Strongly "typed" errors - Java
• Limitations on values of parameters (Eiffel)
• Capacity limitations
• Requests for undefined information
• Restrictions on the order of operations
  (encapsulation?)
• Detection of actions which are likely to be
  unintentional (defined how?)

21
Error Indication II

• Sufficiency - ensure your module will work
  correctly or complain
• Priority of Traps - multiple error handling?
• Size of Trap Vector - how many commands in one
  trap trycatch
• State after Trap - Atomicity
• Errors of Mechanism - tradeoff between simplicity
  and detail

22
Redundancy and Efficiency

• Redundant error checks slow the system
• Can often be removed in later versions
• Retain upper level, remove lower
• Retain lower, remove upper
• Which is best, and why?

23
Reliability/Dependability

• How does UE handling relate to reliability and
  dependability?

24
Conclusion

• Things go wrong
• UE detection and handling is good
• Must be correctly implemented to be useful