<p><a href="https://en.wikipedia.org/wiki/Exception_handling_(programming)#History" rel="noreferrer">According to Wikipedia</a>:</p>
<blockquote>
<p>The cleanup behavior now generally called &quot;finally&quot; was introduced in NIL (New Implementation of LISP) in the mid- to late-1970s as UNWIND-PROTECT. This was then adopted by Common Lisp.</p>
</blockquote>
<p>When did other languages begin to adopt this functionality (and rename it <code>finally</code>)?</p>
<p>I have not yet found any languages developed in the 80s supporting this functionality. Ada 83 has exception handling but no <code>finally</code>. Contemporaneous versions of Pascal didn't have exception handling. Modula-2 and Oberon didn't either (although this was added much later). C++ added exception handling in 1990 but they (purposefully) did/do not support <code>finally</code>.</p>
<p>I haven't been able to figure out when Objective-C, Perl, or Erlang added exception handling support.</p>
<p>Anyhow, skipping ahead to 1996, Borland Delphi, Java, and Python all have <code>finally</code> and Ruby has <code>ensure</code>. What exactly am I missing between the late 70's and the mid-90's?</p>

<history>
The history of "finally" in exception handling?
CC BY-SA 4.0
2023-11-10T06:57:01.230Z
Strictly speaking, Delphi introduced try-finally-end and try-except-end which are distinct. The first case is used heavily for e.g. destruction of manually-created objects, but doesn't come with the full overhead of exceptions.
Mark Morgan Lloyd
CC BY-SA 4.0
2023-11-10T17:46:35.030Z
`UNWIND-PROTECT` was also in MacLisp, I thought NIL and Common Lisp inherited it from there.
Barmar
CC BY-SA 4.0
2023-11-13T21:23:55.777Z
`UNWIND-PROTECT` was addd to Maclisp in Sep 1978. Though it could be that it was coming from Lisp Machine Lisp and/or NIL.
Rainer Joswig
<p>This probably isn't a complete answer, but Microsoft introduced a nonstandard <code>__finally</code> mechanism in their Structured Exception Handling feature. It's a feature of Visual C++ and some aspects are backed by Win32 API functions.</p>
<p>From <a href="https://en.wikipedia.org/wiki/Microsoft-specific_exception_handling_mechanisms" rel="noreferrer">Microsoft-specific exception handling mechanisms</a>:</p>
<blockquote>
<p>It features the <code>finally</code> mechanism not present in standard C++ exceptions (but present in most imperative languages introduced later).</p>
</blockquote>
<p>The references quoted on that page don't support an early introduction date (Matt Pietrek wrote about SEH in 1997), but my recollection was that this feature was present in Visual C++ in the early 1990s. I am fairly certain its introduction preceded the <code>finally</code> keyword in Java.</p>

CC BY-SA 4.0
2023-11-10T00:14:21.153Z
2023-11-10T00:14:21.153Z
Greg Hewgill
CC BY-SA 4.0
2023-11-10T00:56:13.007Z
I'll wait to see what other answers I get, but there does seem to be evidence this is from 1995 at the latest ( https://www.google.com/books/edition/Microsoft_Visual_C++/_5wZAQAAIAAJ?hl=en&gbpv=1&bsq=%22__finally%22 )
Stumpy Joe Pete
CC BY-SA 4.0
2023-11-10T01:07:27.480Z
And here suggests 1993 at the latest: https://groups.google.com/g/comp.os.ms-windows.programmer.tools/c/oekew-NBEEY/m/w-z83jBZ6MQJ
Stumpy Joe Pete
CC BY-SA 4.0
2023-11-10T08:01:58.280Z
That Wikipedia article needs some work. `__finally` is a feature of MSVC (as you said), not of SEH as such. It's available in C as well as C++, and they may have added it just for C, where it's actually needed (in the presence of SEH) since you can't accomplish the same thing with destructors.
benrg
<p><strong>MDL in 1977</strong></p>
<p>The <a href="http://www.ifarchive.org/if-archive/infocom/info/MDL_Primer_and_Manual.pdf" rel="nofollow noreferrer">MDL Primer and Manual (PDF)</a> from 1977 documents <code>UNWIND</code>. MDL is a slightly unusual variant of Lisp.</p>
<p><em>Page 150, 16.6 <code>UNWIND</code></em></p>
<blockquote>
<p>UNWIND is an FSUBR that takes two arguments, usually FORMs. It EVALs
the first one, and, if the EVAL returns normally, the value of the
EVAL call is the value of UNWIND. If, however, during the EVAL a
non-local return attempts to return below the UNWIND FRAME in the
control stack, the second argument is EVALed, its value is ignored,
and the non-local return is completed. The second argument is
evaluated in the environment that was present when the call to UNWIND
was made. This facility is useful for cleaning up data bases that are
in inconsistent states and for closing temporary CHANNEls that may be
left around. FLOAD sets up an UNWIND to close its CHANNEL if the user
attempts to ERRET without finishing the FLOAD. Example:</p>
<pre><code>&lt;DEFINE CLEAN ACT (&quot;AUX&quot; (C &lt;OPEN &quot;READ&quot; &quot;A FILE&quot;&gt;))
  #DECL ((C) &lt;OR CHANNEL FALSE&gt; ...)
  &lt;COND (.C
         &lt;UNWIND &lt;PROG () ... &lt;CLOSE .C&gt;&gt;
                 &lt;CLOSE .C&gt;&gt;)&gt;&gt;
</code></pre>
</blockquote>
<p><em>Above defines a function with a local parameter <code>C</code>, which is the result of opening a file to read. It's either a channel or <code>FALSE</code>.
If <code>C</code> is a channel then, protected, by an <code>UNWIND</code>, then some operations in the <code>PROG</code> expressions are executed. If there is a non-local transfer out of this <code>UNWIND</code>, the second form, a <code>CLOSE</code> operation is executed.</em></p>
<p>In Common Lisp this would be roughly:</p>
<pre><code>(defun clean (&amp;aux (c (open &quot;a file&quot; :direction :input)))
  (declare (type (or channel null) c))
  (when c
    (unwind-protect (progn ... )
      (close c))))
</code></pre>
<p><strong>Maclisp in 1978</strong></p>
<p>Maclisp documents <code>UNWIND-PROTECT</code> in Sept. 1978: <a href="http://ml.cddddr.org/lispnews/lispnews-19780916.html" rel="nofollow noreferrer">http://ml.cddddr.org/lispnews/lispnews-19780916.html</a></p>
<p><strong><code>(UNWIND-PROTECT &lt;e&gt; u1 u2 ... u&lt;n&gt;)</code></strong></p>
<pre><code>  The form &lt;e&gt; will be evaluated, but if the stack is &quot;unwound&quot; past
  the point of the UNWIND-PROTECT for ANY REASON,
  then the unwinder must cause the evaluation, in order,
  of u1 through u&lt;n&gt; in the environment that obtains by first 
  unwinding to the stack point of the UNWIND-PROTECT; then the 
  unwinding may continue.  If &lt;e&gt; terminates normally, then
  the value will be that obtained from &lt;e&gt;, but the forms u1 
  through u&lt;n&gt; will be evaluated also.  The intent is
  that the operation of &lt;e&gt; will do some things that need to be
  undone after sucessful completion, but which can not be undone 
  merely by lambda-binding (eg, closing an opened file).  Thus any 
  aborting of the evaluation of &lt;e&gt; will not leave undesired states 
  hanging around.  Before the u&lt;n&gt;'s are run, NOINTERRUPT is set to
  T, so that asynchronous conditions cannot cause premature termination
  of the handlers.  It is restored to its previous value upon
  completion of the u&lt;n&gt;'s.  If a THROW is done, the user must reset
  NOINTERRUPT to the value he wishes it to be!  The UNWIND-PROTECT
  frame is removed from the stack BEFORE the u&lt;n&gt;'s are run so that
  they may freely do THROWS (et al.).
</code></pre>
<p>It was also in NIL (New Implementation of Lisp) and Lisp Machine Lisp. In the early 80s it was also defined by Common Lisp (Common Lisp the Language, 1984, p 140-142).</p>

CC BY-SA 4.0
2023-11-13T21:50:16.557Z
2023-11-14T15:53:11.110Z
2023-11-14T15:53:11.110Z
Rainer Joswig
# The history of "finally" in exception handling?
Posted by: username_0 on 2023-11-09
[According to Wikipedia](https://en.wikipedia.org/wiki/Exception_handling_(programming)#History):

> The cleanup behavior now generally called "finally" was introduced in NIL (New Implementation of LISP) in the mid- to late-1970s as UNWIND-PROTECT. This was then adopted by Common Lisp.

When did other languages begin to adopt this functionality (and rename it `finally`)?

I have not yet found any languages developed in the 80s supporting this functionality. Ada 83 has exception handling but no `finally`. Contemporaneous versions of Pascal didn't have exception handling. Modula-2 and Oberon didn't either (although this was added much later). C++ added exception handling in 1990 but they (purposefully) did/do not support `finally`.

I haven't been able to figure out when Objective-C, Perl, or Erlang added exception handling support.

Anyhow, skipping ahead to 1996, Borland Delphi, Java, and Python all have `finally` and Ruby has `ensure`. What exactly am I missing between the late 70's and the mid-90's?
**Tags:** history
> **Comments:**
> **username_1**: Strictly speaking, Delphi introduced try-finally-end and try-except-end which are distinct. The first case is used heavily for e.g. destruction of manually-created objects, but doesn't come with the full overhead of exceptions.  
> **username_2**: `UNWIND-PROTECT` was also in MacLisp, I thought NIL and Common Lisp inherited it from there.  
> **username_3**: `UNWIND-PROTECT` was addd to Maclisp in Sep 1978. Though it could be that it was coming from Lisp Machine Lisp and/or NIL.  
---
## 2 answers
### Answer by username_4 on 2023-11-10. Score: 6
This probably isn't a complete answer, but Microsoft introduced a nonstandard `__finally` mechanism in their Structured Exception Handling feature. It's a feature of Visual C++ and some aspects are backed by Win32 API functions.

From [Microsoft-specific exception handling mechanisms](https://en.wikipedia.org/wiki/Microsoft-specific_exception_handling_mechanisms):

> It features the `finally` mechanism not present in standard C++ exceptions (but present in most imperative languages introduced later).

The references quoted on that page don't support an early introduction date (Matt Pietrek wrote about SEH in 1997), but my recollection was that this feature was present in Visual C++ in the early 1990s. I am fairly certain its introduction preceded the `finally` keyword in Java.
> **Comments:**
> **username_0** (2023-11-10): I'll wait to see what other answers I get, but there does seem to be evidence this is from 1995 at the latest ( https://www.google.com/books/edition/Microsoft_Visual_C++/_5wZAQAAIAAJ?hl=en&gbpv=1&bsq=%22__finally%22 )  
> **username_0** (2023-11-10): And here suggests 1993 at the latest: https://groups.google.com/g/comp.os.ms-windows.programmer.tools/c/oekew-NBEEY/m/w-z83jBZ6MQJ  
> **username_5** (2023-11-10): That Wikipedia article needs some work. `__finally` is a feature of MSVC (as you said), not of SEH as such. It's available in C as well as C++, and they may have added it just for C, where it's actually needed (in the presence of SEH) since you can't accomplish the same thing with destructors.  
---
### Answer by username_3 on 2023-11-13. Score: 5
MDL in 1977
The MDL Primer and Manual (PDF) from 1977 documents UNWIND. MDL is a slightly unusual variant of Lisp.
Page 150, 16.6 UNWIND

UNWIND is an FSUBR that takes two arguments, usually FORMs. It EVALs
the first one, and, if the EVAL returns normally, the value of the
EVAL call is the value of UNWIND. If, however, during the EVAL a
non-local return attempts to return below the UNWIND FRAME in the
control stack, the second argument is EVALed, its value is ignored,
and the non-local return is completed. The second argument is
evaluated in the environment that was present when the call to UNWIND
was made. This facility is useful for cleaning up data bases that are
in inconsistent states and for closing temporary CHANNEls that may be
left around. FLOAD sets up an UNWIND to close its CHANNEL if the user
attempts to ERRET without finishing the FLOAD. Example:
))
  #DECL ((C)  ...)
  >
                 >)>>


Above defines a function with a local parameter C, which is the result of opening a file to read. It's either a channel or FALSE.
If C is a channel then, protected, by an UNWIND, then some operations in the PROG expressions are executed. If there is a non-local transfer out of this UNWIND, the second form, a CLOSE operation is executed.
In Common Lisp this would be roughly:
(defun clean (&aux (c (open "a file" :direction :input)))
  (declare (type (or channel null) c))
  (when c
    (unwind-protect (progn ... )
      (close c))))

Maclisp in 1978
Maclisp documents UNWIND-PROTECT in Sept. 1978: http://ml.cddddr.org/lispnews/lispnews-19780916.html
(UNWIND-PROTECT  u1 u2 ... u)
  The form  will be evaluated, but if the stack is "unwound" past
  the point of the UNWIND-PROTECT for ANY REASON,
  then the unwinder must cause the evaluation, in order,
  of u1 through u in the environment that obtains by first 
  unwinding to the stack point of the UNWIND-PROTECT; then the 
  unwinding may continue.  If  terminates normally, then
  the value will be that obtained from , but the forms u1 
  through u will be evaluated also.  The intent is
  that the operation of  will do some things that need to be
  undone after sucessful completion, but which can not be undone 
  merely by lambda-binding (eg, closing an opened file).  Thus any 
  aborting of the evaluation of  will not leave undesired states 
  hanging around.  Before the u's are run, NOINTERRUPT is set to
  T, so that asynchronous conditions cannot cause premature termination
  of the handlers.  It is restored to its previous value upon
  completion of the u's.  If a THROW is done, the user must reset
  NOINTERRUPT to the value he wishes it to be!  The UNWIND-PROTECT
  frame is removed from the stack BEFORE the u's are run so that
  they may freely do THROWS (et al.).

It was also in NIL (New Implementation of Lisp) and Lisp Machine Lisp. In the early 80s it was also defined by Common Lisp (Common Lisp the Language, 1984, p 140-142).
---
