Exception Handling IV: try/catch a switch?

[Samuel A. Figueroa]

First, I would like to just make a passing comment that for my master's
thesis I designed a programming language to allow access to all the fea-
tures of the IEEE standard.  It feels nice to see other people suggest
things that are features of my language.  I would hasten to add, however,
that what I did was definitely NOT research work, so that I would have
no basis on which to urge that these features be adopted.

Because I am most familiar with the Intel 80X86 architecture (many inex-
pensive computers use CPUs with this architecture), it occurred to me
that another way for hardware to handle exceptions is to have an excep-
tion mask indicating which exceptions one is interested in, and a bit
in every fp opcode indicating whether a signal should be generated in
case an unmasked exception occurs.  This would eliminate the need for
a synchronizing instruction as well as branching instructions.  And as
long as no opcode with this bit set is encountered, the pipeline should
not be disrupted.  The cost of taking a trap might be tolerable when
an exception occurs.  Such a trap could implement presubstitution, or
some other scheme.  I am just expressing an idea that occurred to me on
the spur of a moment.

As for syntax, I see two things that need to be indicated: which opera-
tions are interesting from the point of view of the exceptions they may
generate, and what to do when those exceptions occur.  I don't feel the
same syntactical construct needs to do both.  From the point of reada-
bility, I would prefer that they be separate constructs.  In my language,
in every construct in which a sequence of statements could be embedded,
one could specify exception handlers in a way similar to a switch state-
ment in C.  If such exception handlers need to apply only to one parti-
cular statement, one could write that statement as a block construct.
Usually, when I read code, I prefer to think about what happens in the
normal case, and then be able to easily find the code that handles
exceptional cases.

As for being able to nest exception handlers, I feel it ought to be up
to the programmer as to how complicated he wants his program to be.
Probably in most cases exception handlers would not be nested even if
it were possible to do so, but if this feature were needed, it ought
to be available somehow.

Just some thoughts ...
Sam