The history of throw?

[Steven T. Hatton]

I just read the section in _The_GNU_Emacs_Lisp_Reference_Manual_
on /Explicit/ /Nonlocal/ /Exits/[*] and had to wonder what language first
introduced the idea of throwing, catching, and unwinding. Note that
(Emacs) Lisp does not have something called 'exception', nor does it have a
'try' keyword. So what we find in C++ is certainly not taken from Lisp
without modification if indeed it was influenced by Lisp at all. I've read
that the concept of 'stack unwinding' was borrowed from Lisp. Does anybody
know the details of this history?

http://www.gnu.org/software/emacs/elisp-manual/html_node/elisp_130.html#SEC130
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[E. Robert Tisdale]

What language first introduced the idea of throwing, catching, and unwinding.

Fortran.

"The alternate RETURN allows a procedure to return
to one of the several labelled statenebts in the calling program unit
dependent upon the value of an integer variable."

 

[E. Robert Tisdale]

Fortran.

"The alternate RETURN allows a procedure to return
to one of the several labelled statenebts in the calling program unit

to one of the several labelled statements in the calling program unit

 

[Andrew Koenig]

I just read the section in _The_GNU_Emacs_Lisp_Reference_Manual_
on /Explicit/ /Nonlocal/ /Exits/[*] and had to wonder what language first
introduced the idea of throwing, catching, and unwinding.

Probably PL/I, in approximately 1968.

 

[osmium]

I just read the section in _The_GNU_Emacs_Lisp_Reference_Manual_
on /Explicit/ /Nonlocal/ /Exits/[*] and had to wonder what language first
introduced the idea of throwing, catching, and unwinding.

Probably PL/I, in approximately 1968.

Just a guess, but my guess is PL/I also.

 

[Steven T. Hatton]

Fortran.

"The alternate RETURN allows a procedure to return
to one of the several labelled statenebts in the calling program unit
dependent upon the value of an integer variable."

As regards C++, which was the overall topic of my post, I must say there are
many aspects of Lisp error handling combined with catch and throw that seem
to clearly indicate a common origin. Even the concept of RAII seems to be
present. There are differences, but I am specifically interested in what
influences contributed to C++'s exception handling mechanism. Here is a
list of similarities I've noticed between Lisp and C++ regarding C++'s
exception handling.

The use of catch and throw. Note that in Lisp these are not intended
primarily for error handling, but they have clear similarities with the
error handling mechanism.

The use of error symbols is very similar to the use of exceptions in C++.
* Error symbols are arranged in a hirearchie with 'error' at the root. This
is analogous to the derivation hirearchie in the Standard Library.
* Error symbols carry with them a string intended for printing human
readable messages. This is analogous to the string returned by
std::exception::what() in C++
* Error symbols are passed up the call stack to until they encounter a
handler that accepts their type. Clearly analogous to the C++ mechanism of
using multiple catch() statements.
* If no handler is encountered, the process is terminated.

As the forms are exited, all local variable are unbound.

Though technically more similar to Java's finally than C++'s destructor, the
'unwind-project' 'cleanup-forms' serve an analogous purpose. To use C++
terminology, they ensure the essential invariants are preserved: " The
unwind-protect construct is essential whenever you temporarily put a data
structure in an inconsistent state; it permits you to make the data
consistent again in the event of an error or throw."


--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Richard Herring]

Fortran.

"The alternate RETURN allows a procedure to return
to one of the several labelled statenebts in the calling program unit
dependent upon the value of an integer variable."

That's just syntactic sugar for writing "if (<hidden return value>) goto
<a label elsewhere in this function>;" immediately after the function
call. There's no equivalent of unwinding the call stack or catching.

 

[E. Robert Tisdale]

That's just syntactic sugar for writing
"if (<hidden return value>) goto <a label elsewhere in this function>;"
immediately after the function call.
There's no equivalent of unwinding the call stack or catching.

Neither Fortran or C++ specify a stack much less stack unwinding.
The point is that the notion of exception handling appears
in the earliest high level computer programming languages.

 

[osmium]

The point is that the notion of exception handling appears
in the earliest high level computer programming languages.

Tell us what facilities for handling exceptions were provided in Fortran II.

 

[Ron Natalie]

Neither Fortran or C++ specify a stack much less stack unwinding.
The point is that the notion of exception handling appears
in the earliest high level computer programming languages.

Actually, while C++ doesn't define the stack (at least not in
the concept of using it for subroutine linkage), it does use
the term "stack unwinding" in the description of getting from
the point of throw to the catch, destroying local variables
along the way.

 

[Dave Vandervies]

Actually, while C++ doesn't define the stack (at least not in
the concept of using it for subroutine linkage),

It does define a subroutine call mechanism that's required to look,
feel, and smell like a stack, though.

it does use
the term "stack unwinding" in the description of getting from
the point of throw to the catch, destroying local variables
along the way.

Wouldn't it be the (abstract) function-invocation stack that this refers
to, and not necessarily something like the hardware-supported stack that
most general-purpose processors use to implement such a thing?


dave

 

[Richard Herring]

Neither Fortran or C++ specify a stack much less stack unwinding.

The words "stack" and "unwinding" may not be used, but C++ provides for
(a) transferring control *an unspecified number of layers layer out* in
a sequence of nested function calls, (b) cleaning up everything which
goes out of scope as a result of this.

Fortran doesn't.

The point is that the notion of exception handling appears
in the earliest high level computer programming languages.

Possibly, but you haven't demonstrated it.

 

[Jerry Coffin]

[ ... ]

Possibly, but you haven't demonstrated it.

FORTRAN didn't. PL/I would be the next obvious choice -- it not only
had exception handling, but more or less forced its use on a regular
basis, because it used it for quite a few situations that really
weren't exceptional. One obvious example was reading a file, with the
end of the file being signaled by an exception.

It's certainly true that PL/I's exception handling was (both
syntactically and semantically) substantially different from C++'s,
but I think almost anybody who studied the two would agree that the
similarities are sufficient to say it really WAS exception handling as
the term is normally used.