[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
no subject (file transmission)
- To: email@example.com
- Subject: no subject (file transmission)
- From: Charles (Froggy) Fiterman <firstname.lastname@example.org>
- Date: 18 Dec 92 08:44:10 CST (Fri)
- Resent-date: Fri, 18 Dec 92 12:26:55 PST
- Resent-from: Urs Hoelzle <urs@otis>
- Resent-message-id: <9212182026.AA09545@otis.Stanford.Edu>
- Resent-to: real-self-interest
>I'd never heard of ContinueUnwind - do any other languages support it?
>What about nested unwind protect blocks? If an outer unwind protect does
>a continue unwind, do inner protected blocks get executed first? I guess
Yes inner blocks run first.
>that would make sense, but perhaps not always. What if the inner protected
>block closed something that needs to remain open in order to continue
That would be a bug. The function of unwind protect blocks, also called always
blocks because they always get to run when a function ends, is that each block
gets to clean up after itself. If a block opens a file it gets to close that
file even if something it calls does some form of exit.
Unwind protect blocks are most usefull in languages that support backtracking
and generators. A function opens a file and returns a record by suspending
when backtracked it returns the next record. If control passes outside the
range where the function can be backtracked the function's always block is
called and the function gets to close its file.
Unwind protect blocks can clearly be misused, so can anything. Their function
is to improve modularity by allowing functions to do their own cleanup.
A usefull friend of these blocks is the abort string. The abort string is
normally null. Functions signal serious error by placing a messages on the
abort string. When the abort string is non null control begins falling through
unwind protect blocks. While in such a block control proceeds normally. The
unwind protect block may clear or add to the abort string. If it becomes null
again control passes normally.
In terms of practical programming few error conditions can be expressed as an
int, which is what most error flags are. Further if you call a system function
such as open and fail 99% * of the time all you can do is give a message and
die. Successfull languages like Pascal often do that with no recource. 1% of
the time there is something intelligent to do if open fails, but that 1% occurs
in system software. Having open put a message on the abort string gives the
best of both worlds, you crash normally but with a little trouble you can
recover. In general the function that detects an error can create the best
error message, its caller may be able to add details. This strategy encourages
* 96.7 precent of statistics are made up on the spot.