[mercury-users] Exceptions and unique modes

[Richard A. O'Keefe]

	This is quite a serious problem for the reasons Peter points out:
	robust code has to be able to survive unexpected exceptions and clean
	up afterwards.
	
I used to be a big fan of exceptions; I was the one who designed and
implemented the Quintus exception facility (and I submitted a paper
about it to an LP conference the year *before* BIM did, only Quintus
screamed and demanded that it be yanked).

The longer I live, the less I believe in them, precisely because they
do really horrible things to data flow and even control flow analysis.
Read some of the stuff that was written during the development of
Ada 95.  Basically, exceptions mean that almost any place can go to
almost any place, and you never quite know what state things are in.

I think there is ONE place where "has to be able to survive unexpected
exceptions" is true, and that is where a program loads more code at
run time and has good reason not to trust it.  I met this in a student
Algol compiler at the University of Auckland.  It's one of the reasons
why Java has exceptions, and one of the reasons why Quintus Prolog has
them.

Suppose, however, you are writing a program such as a Web server.
You don't have to handle unexpected *exceptions*,
you have to handle unexpected *events*.

Erlang programs are made up of lots and LOTS of communicating processes
which cannot alter shared values.  If you want to tell another process
something unexpected has happened, and the process looks at the message
when it chooses to, and it processes the message when it chooses to,
without the slightest hazard to its internal data structures.

When you decide to let unexpected events be modelled as exceptions,
what you are doing is handing control of process X over to process Y,
so it is no wonder if managing process X gets hard.

In short, it's not time to fix exceptions, it's time to use a different
and less dangerous mechanism.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------