Is a throw exception evaluated by the abstract machine?

Question

According to intro.abstract#1:

... conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.

This explanation is the as-if rule, which contains the following example:

... an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced.

The definition of a side-effect is in intro.execution#7:

Reading an object designated by a volatile glvalue ([basic.lval]), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. ...

It seems to me that in the following program:

int main() 
{
  throw 42;
}

The value of the expression throw 42; is not used, and it doesn't satisfy any of the criteria of being a side-effect.

Does that mean the implementation is allowed to not evaluate this expression? Is the above program equivalent to:

int main() {}

as far as the abstract machine is considered? I can't find any text that says the abstract machine knows or cares about exceptions.

Answer 1

The (edited) question boils down to whether the compiler is allowed to "optimize" int main() { throw 42; } to just int main() { }. I believe the answer is negative in this case, because the thrown exception causes a change in the observable behavior of the program, which the compiler is required to emulate.

Since there is no explicit handler defined, throw 42; is supposed to invoke std::terminate() which, in turn, ends up calling std::abort(), where "an implementation defined status is returned to the host environment that indicates unsuccessful execution". In other words, the exit code of the program would be different with vs. without the exception being thrown, and therefore the throw cannot be ellided.

(This leaves out the case of freestanding implementations where there is no "host" to return to, but I don't think the compiler is allowed to make assumptions about the environment where it will run.)

In the more general case when there is an explicit matching exception handler defined in the user code, it becomes fuzzier. Throwing the exception transfers control to that handler, but if the compiler can establish that the handler causes no changes in the observable behavior or other side-effects, then the whole throw may be optimized out. That could happen in cases where the handler does not access any volatile data, does not modify any object, does not call any library I/O functions, and performs a program exit equivalent to the normal one.

Answer 2

There is one thing one should remember about the "as if rule": it doesn't exist as such, in C, C++, Java or high level languages in general.

There are rules about the identifiers: what they can contain, what they must start with, what they can't be (reserved words). There are rules about grammar. About overflow.

And each of these rules could have been different, these rules aren't exactly the same in other programming languages (compare overflow in Java and in C++). The so called as if rule is different at the meta level, as such it isn't a rule but an observation. It's a comment and it cannot be removed from the C++ standard or any language specification because it isn't a rule of the specification, it describes what the specification is.

As if you wrote in a printed book "this book is printed with ink" and later removed the mention, the book would still have nearly as much ink. Or if you added to the C++ specification "this specification is written in English" and later removed the mention, the rest would still be in English.]

What people call a "rule" is a reminder of the essence of the description of the programming language standard.

You can only apply the so called as if "rule" to a complete well formed, compilable program; there is no as if rule for statements or expressions.

The semantics of each statement, subexpression, etc. is described by language semantics; applied to a whole, complete, valid program, the semantics defines the set of possible outputs of a program.

If you have a program that can run, the "rule" just says that conformance is defined by measuring the program I/O (including volatile access, which is a kind of I/O just like stdio, and returning from main/calling exit).

Summary: your question as such is meaningless and you should forget there is something called "as if rule", because it can't be made into a distinct, removable rule.

NOTE

The value of the expression throw 42; is not used, and it doesn't satisfy any of the criteria of being a side-effect.

Because a throw expression throws an exception, it doesn't result in a "value" like the 42 part. It has an effect: its throws the exception, to stop normal control flow and jump to an exception handler or exit the program completely if none is present.

In term of "abstract machine", throwing certainly does something: it stops the usual execution in the abstract machine. In the abstract machine, you can see the effect of a throw.

Asking about "abstract machine" seems to contradict your whole point as any computation is visible in the abstract machine, but the abstract machine is not visible.

Anyway, all these dissertations only prove my point that "abstract machine", "as if rule"... are noxious concepts that don't help anyone.

Just consider program semantics, which is always defined in term of I/O in all high level languages. Forget the rest!