Exception Handling: Issues and a Proposed Notation

1
Exception Handling Issues and a Proposed Notation

• -John B Goodenough
• Appeared in Communications of the ACM, December
  1975
• Presented by Santosh Kumar, OSU

2
Introduction

• Exceptions Conditions brought to the attention
  of the operations invoker
• Raising an Exception Bringing an exception
  condition to the invokers attention
• Handling an Exception Invokers response

3
Use of Exception

• Deal with an operations actual or impending
  failure Range failure domain failure
• Indicate the significance of a valid result or
  the environment under which it was obtained
• Permit an invoker to monitor an operation

4
Why use Notation for Exceptions?

• Notations help prevent and detect programmer
  errors. Common programmer errors are
• Forgetting that an operation can raise a
  particular exception
• Associating a handler with the wrong activation
  point
• Associating a handler with the wrong exception

5
Previous Exception Handling Techniques

• Subroutines Exception handler coded as a
  subroutine and passed as a parameter
• Labels Handler begins at the statement whose
  label is passed as a parameter
• Status Variables An Integer valued parameter is
  assigned a value before returning from an
  operation

6
Exception Handling Requirements and Issues

• Association of handlers with invocation of
  operations
• Control Flow Issues
• Default Exception Handling
• Hierarchies of operations and their exceptions

7
Associating Exception Handlers with Operations

• Operation Any subroutine
• Invocation An attempt to execute the operation
• Activation Point The place in code from which
  an operation is invoked

8
Proposed Notation

• Explicit Declaration of what exceptions an
  operation can raise.
• Static Association of exception handlers with
  activation points (association defined at compile
  time rather than at run time)

9
Examples of Static Handler Association

• Procedure Calls
• CALL G(A)Xhandler-action
• Expression containing operators
• (AB) OVERFLOW
• or (A/F(B)) OVERFLOW
• ZERODIVIDE
• x

10
Static Association of Exception Handlers
ltfunction callgt ltfunction namegt (ltparameter
listgt) lthandler groupgt
ltprocedure callgt CALL ltprocedure namegt
(ltparameter listgt) lthandler groupgt
ltassignmentgt ltvariablegt ltexpressiongt)
lthandler groupgt
ltloopgt DOltloop formgt ltstatementgt) END
lthandler groupgt
ltconstantgt ltquantitygt ltloop
formgt ltfunction callgt

ltquantitygt ltexpressiongt ltexpre
ssiongt ltquantitygt
ltquantitygt ltexpressiongt
ltexpressiongt
ltexpressiongt lthandler groupgt
ltunary operatorgt
ltbinary operatorgt

11
Static Association of Exception Handlers (contd.)
ltsubroutine definitiongt ltlabelgt PROCEDURE
(ltparameter name listgt)
ltexception declarationgt
ltstatementgt END lthandler groupgt
lthandler groupgt ltexception namegt
ltstatementgt
12
Issues and requirements for association of
handlers with exceptions

• Methods for associating handlers with exceptions
  should help prevent and detect errors
• Deal uniformly with exceptions raised by language
  defined operations and programmer-defined
  operations
• Cost of setting up an exception handler
  association should be low relative to the cost of
  activating the handler. (Exceptions occur only
  rarely)

13
Proposed methods advantages

• The proposed static association method of
  associating handlers together with exception
  declaration make it possible for compiler to
  detect failure to deal with every exception an
  operation can raise
• It deals uniformly with language-defined
  exceptions and programmer defined exceptions.

14
Control Flow Issues

• To guard against error, each exception should
  have its resumption or termination constraints
  specified explicitly
• It will help to detect violations of these
  constraints at compile time

15
Proposed Notation

• Three types of exceptions
• ESCAPE exceptions require termination
• NOTIFY exceptions forbid termination
• SIGNAL exceptions permit termination but not
  required
• Every exception must be declared to be one of
  these types

16
Examples

• Declare as
• DCL F ENTRY(FIXED) XESCAPE, YSIGNAL
• Raise as
• SIGNAL Y
• NOTIFY X

17
Returning from Handler

• The EXIT Command terminate
• EXIT(value) equivalent to RETURN
• EXIT control flows to the next statement
• The RESUME Command Return the control to the
  operation raising the exception

18
Other Exceptions

• The ENDED Exception Raised whenever an
  operation terminates normally.
• The CLEANUP Exception Needed if an operation is
  not resumed from a SIGNALed exception handler

19
Default Exception Handling - Requirements

• Declaration of default exceptions
• Programmer defined default handlers
• Uniformity
• Explicit invocation of default handlers

20
Proposed Notation

• Use OPTIONAL keyword
• Declare as
• DCL FXESCAPE, ZSIGNAL OPTIONAL
• Call as
• CALL F
• CALL FXRESUME(DEFAULT)

21
Conclusion

• The wide variety of exception handling approaches
  can be replaced with a single uniform and
  reliable approach.