Hello everyone,

If an exception is *explicitly* raised during a variable assignment, what
happens to the variable contents? Are they in an undefined ("abnormal")
state, or are the previous contents preserved?

For example:
```
with Ada.Text_IO;
procedure Test is
function Always_Raises return Integer is
begin
raise Program_Error;
return 1;
end Always_Raises;

I : Integer := 0;
begin
-- insert a nested handler, because the ARM § 11.4 ¶ 3 *does*
-- say that the currently executing body is "abnormally
-- completed" (including finalizing everything) before
-- entering the exception handler
begin
I := Always_Raises;
exception
when others => null;
end;
Ada.Text_IO.Put_Line(Integer'Image(I));
end;
```
What, if anything, will be printed? (Disclaimer: I know the preexisting
variable value will be preserved in GNAT specifically, but I'm asking if
the standard guarantees that's the case)

I read through the ARM 2012 § 11 and § 5.2, as well as skimming through
everything related to “assignment” and “exceptions” in the ARM index;
and didn't see much relating to this. All I saw is this:
> When an exception occurrence is raised by the execution of a given
> construct, the rest of the execution of that construct is abandoned
— ARM 2012 § 11.4 ¶ 3
Which I guess implicitly protects variable values since assigning to a
variable is performed after evaluating the right hand side, but still not
necessarily a clear answer.

I did see in § 13.9.1 that language-defined validity checks (e.g. bounds
checks) failing or calling `abort` in a task during an assignment will
cause the variable to enter an "abnormal" (i.e. invalid) state, but that
doesn't cover user-raised exceptions.

--
~nytpu

On 2022-11-20 19:03, nytpu wrote:
>
> If an exception is *explicitly* raised during a variable assignment, what
> happens to the variable contents? Are they in an undefined ("abnormal")
> state, or are the previous contents preserved?

If the exception occurs during evaluation of the RHS, as in your example, then
the language guarantees that the value of the LHS is unchanged. The execution of
the assignment statement is abandoned before the value of the LHS is changed.

If an exception is raised while adjusting a controlled LHS, then the value of
the LHS has already been changed before the exception is raised.

> -- insert a nested handler, because the ARM § 11.4 ¶ 3 *does*
> -- say that the currently executing body is "abnormally
> -- completed" (including finalizing everything) before
> -- entering the exception handler

This comment is false. Finalization does not occur until the exception handler
finishes. Exception handlers would be pretty useless otherwise.

--
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail
15