Semantics fix: unhandled exceptions must still unwind.

* unwind.c (unhandled_ex): New static structure.
(unwind_to_exit_point): The code to print the unhandled exception info
and bail the process is moved here out of uw_throw. We do this in the
situation when we have an unhandled exception, which is represented
by the fact that the exception pointer points to the unhandled_ex
structure.
(uw_throw): If unhandled hook isn't a function, we don't abort; we go
through the unwinding and unhandled processing. Also, ditto if the
unhandled function returns, ditto. Unhandled processing is entered
by substituting unhandled_ex for the not-found exception, and
allowing unwind_to_exit point to be called.

* txr.1: Document new behavior for unhandled exceptions
and *unhandled-hook*.

1 files changed, 16 insertions, 13 deletions

diff --git a/txr.1 b/txr.1
index f8b2202e..44fe5eb8 100644
--- a/txr.1
+++ b/txr.1
@@ -28237,14 +28237,17 @@ macro.
 If no catch or accepting handler is found, control is transferred
 to the function stored in the
 .code *unhandled-hook*
-variable. If that function returns, the process terminates.
+variable. If that function returns, then unwinding is performed
+after which the process terminates (unless the unwinding actions
+intercept the control to prevent that).
 .IP -
 If no catch or accepting handler is found and
 .code *unhandled-hook*
 is
 .codn nil ,
 then a built-in strategy for handling the exception is invoked,
-consisting of printing some informational messages and terminating.
+consisting of unwinding, and then printing some informational messages and
+terminating.
 .PP
 
 From the above it should be evident that there are two ways by which exceptions
@@ -28674,25 +28677,25 @@ with the following arguments: the exception type symbol, the exception object,
 and a third value which is either
 .code nil
 or else the form which was being evaluated when the exception was thrown.
+The call occurs before any unwinding takes place.
 
-Otherwise, if the variable is
+If the variable is
+.codn nil ,
+or isn't a function, or the function returns after being called,
+then unwinding takes place, after which some informational messages are printed
+about the exception, and the process exits with a failed termination status.
+
+In the case when the variable contains a object other than
 .code nil
-some informational messages are printed about the exception, and the process
-exits with a failed termination status.
-In the same situation, if the variable contains an object which is not a
-function, the process terminates abnormally as if by a call to the
-.code abort
-function.
+which isn't a function, a diagnostic message is printed on the
+.code *stderr*
+stream prior to unwinding.
 
 Prior to the function being called, the
 .code *unhandled-hook*
 variable is reset to
 .codn nil .
 
-If the function registered in
-.code *unhandled-hook*
-returns, the process exits with a failed termination status.
-
 Note: the functions
 .code source-loc
 or