[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exception systems



> From: Olin Shivers <shivers@lambda.ai.mit.edu>
> Subject: Re: exception systems
> Date: Thu, 18 Apr 1996 13:35:16 -0400
> 
> > I would like to take a stand against referring to async interrupts as
> > exceptions.
> > [ ... ]
> 
> Thank you, I didn't want to be the first one to throw a stone.  But I
> completely agree with Olin.

I don't _completely_ agree.  He fingers Unix, but it's far more general.
For instance, machines often treat timer interrupts and, say, division
by zero, or illegal-op-code, in very similar ways.

> Here is another one: Does anybody else also think the proposals we've
> seen so far are -- excuse the word -- bloated?  I even read the
> word(s) ``multiple inheritance'' somewhere!  Uuugh!

I have the same feeling, but it's hard to simplify without leaving
out something that looks like it ought to be there.  For instance,
you could leave out "restarts".  It was the restart stuff that most
made me think the CL condition system had too much in in.  But
restarts turned out to be one of the parts of the condition system
I used first and most.

However, it should be possible to design a condition system that
makes sense both with and without restarts; and then you can
simplify by leaving restarts out until there's enough demand for
them.

The Kelsey proposal would also be simplified if it could assume
a standard way of doing records.  Multiple inheritance can
probably be avoided.  Richard Kelsey wrote:

  Conditions are records with multiple inheritance.  Multiple
  inheritance is necessary because recovery strategies for several
  types of conditions might be appropriate for a particular exceptional
  situation.  Multiple inheritance is likely to make field access
  slower than for simple records, but conditions are only used in
  `rare' circumstances.

MI may make filed access slower, though perhaps not by too much.
There are also restricted forms of MI (e.g. in Java) that cost
less.

In any case, MI needs a better rationale, because we probably don't
want conditions to be suitable only for use in rare circumstances.
Nor is MI the only way express that "recovery strategies for several
types of conditions might be appropriate for a particular exceptional
situation."

-- jeff