[mercury-users] exceptions considered bloody annoying

Richard A. O'Keefe ok at cs.otago.ac.nz
Tue Apr 16 15:35:37 AEST 2002 

I wrote:
	> I note that Eiffel's exception handling mechanism is about as
	> unlike 'throw' as you can get.
	
Michael Day wrote:
	Any quick pointers for people who don't know Eiffel? Any lessons that
	could apply to exception handling in Mercury?
	
"Eiffel The Language" (any edition)
"Object-Oriented Software Construction, 2nd ed.", Betrand Meyer.

p417
    Disciplined Exception Handling principle
    There are only two legitimate responses to an exception
    that occurs during the execution of a routine:
    * Retrying: attempt to change the conditions that led
      to the execution and to execute the routine again from the start
    * Failure (also known as organized panic): clean up the environment,
      terminate the call, and report failure to the caller.
    In addition, exceptions resulting from some operationg system
    signals ... may in rare cases justify a 'false alarm' response:
    determine that the exception is harmless and pick up the routine's
    execution where it started.

p419 shows a template for an Eiffel routine:
    <routine> is
      require <precondition>
      local <local declarations>
      do <body>
      ensure <postcondition>
      rescue <rescue clause>
      end

In addition to 'require' (precondition) and 'ensure' (postcondition)
there are also 'check' (assertion) and 'variant' (loop termination);
failure of assertions raises an exception.

    Whenever an exception occurs during the execution of the normal
    <body>, this execution will stop and the <rescue clause> will be
    executed instead.  There is at most one <rescue clause> in a
    routine, but it can find out what the execution was ... so that
    you can treat different kinds of exceptions differently ...

    The other new construct is the retry instruction, written just
    'retry'.  This instruction may only appear in a <rescue clause>.
    Its execution consists in restarting the routine body from the
    beginning. ... a <rescue clause> that does not execute a retry
    leads to a failure.

p420
    [a routine without a rescue clause effectively has an empty one,
     so any exception will result in failure of such a routine with
     no clean-up.]

p431
    [EXECPTIONS.exception is the last exception that occurred]
    [EXCEPTIONS.original_exception is the exception that triggered
     the chain of failures that led to EXCEPTIONS.exception]

p434
    Exception Simplicify Principle
    All processing done in a rescue clause should remain simple,
    and focused on the sole goal of bringing the recipient object
    back to a stable state, permitting a retry if possible.

I've omitted the details showing how this all fits into the precondition/
postcondition machinery and what you have to prove to show that your
exception-handling program is correct.

There seem to be two main differences in spirit:
* there's a strong emphasis on handling exceptions as close to their
  occurrence as possible
* there's the insistence that rescue-retry is just for cleanup; the
  actual processing _should_ be done by the main body of the routine.
  If alternative processing is to be used, then the rescue clause
  should set flags rather than _being_ the alternative processing.
and a difference in practice:
* you are not encouraged to package up a lot of information in an
  'exception object'; exceptions aren't objects.  The narrow bandwidth
  (OK, I'm telling a half truth, I have read about 'developer exceptions')
  between exception raiser and exception handler is again a strong
  incentive to handle exceptions 'locally' where you _know_ what it
  would have told you.

Eiffel is a pure object-oriented language (as C++, Java, and C# are _not_);
all data is held in objects, and one is advised to design so that
excepting code has had as little opportunity to change "uninvolved"
objects as possible.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------

More information about the users mailing list