[mercury-users] Exceptions and unique modes

[Peter Ross]

On Fri, Feb 16, 2001 at 11:31:50AM +1300, Richard A. O'Keefe wrote:
> 	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.

I would be interested to hear how you would write the bit of code which
needs to clean up the map of resources I posted in a previous email in
Erlang.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------