1.1.5 Classification of Errors
Language Design Principles
{
AI12-0204-1}
When the Reference Manual says that some construct
C1 has equivalent
dynamic semantics to some other construct
C2, then there should
be a language rule that says that
C1 is illegal if
C2 is
illegal.
Reason: {
AI12-0204-1}
We do not want to infer Legality Rules from Dynamic Semantics rules.
{
AI12-0064-2}
When the value of an
expression
is needed to enforce a Legality Rule or Post-Compilation Rule, then there
should be a language rule requiring the
expression
to be static (see
4.9).
Implementation Requirements
The language definition
classifies errors into several different categories:
Errors that are required to be detected prior to
run time by every Ada implementation;
These errors correspond to any violation
of a rule given in this document, other than those listed below. In particular,
violation of any rule that uses the terms shall, allowed, permitted,
legal, or illegal belongs to this category. Any program that contains
such an error is not a legal Ada program; on the other hand, the fact
that a program is legal does not mean, per se, that the program
is free from other forms of error.
The
rules are further classified as either compile time rules, or post compilation
rules, depending on whether a violation has to be detected at the time
a compilation unit is submitted to the compiler, or may be postponed
until the time a compilation unit is incorporated into a partition of
a program.
Ramification: See, for example,
10.1.3,
“
Subunits of Compilation Units”,
for some errors that are detected only after compilation. Implementations
are allowed, but not required, to detect post compilation rules at compile
time when possible.
Errors that are required to be detected at run
time by the execution of an Ada program;
The
corresponding error situations are associated with the names of the predefined
exceptions. Every Ada compiler is required to generate code that raises
the corresponding exception if such an error situation arises during
program execution. [If such an error situation is certain to arise in
every execution of a construct, then an implementation is allowed (although
not required) to report this fact at compilation time.]
Bounded errors;
{
AI12-0444-1}
The language rules define certain kinds of errors that are not expected
to be detected either prior to or during run time, but if not detected,
the range of possible effects shall be bounded.
The
errors of this category are called
bounded errors. The possible
effects of a given bounded error are specified for each such error, but
in any case one possible effect of a bounded error is the raising of
the exception Program_Error.
Erroneous execution.
{
AI12-0444-1}
In addition to bounded errors, the language rules
define certain kinds of errors as leading to
erroneous execution.
Like bounded errors, the implementation is not expected to detect such
errors either prior to or during run time. Unlike bounded errors, there
is no language-specified bound on the possible effect of erroneous execution;
the effect is in general not predictable.
Ramification: Executions are erroneous,
not programs or parts of programs. Once something erroneous happens,
the execution of the entire program is erroneous from that point on,
and potentially before given possible reorderings permitted by
11.6
and elsewhere. We cannot limit it to just one partition, since partitions
are not required to live in separate address spaces. (But implementations
are encouraged to limit it as much as possible.)
Suppose a program contains a pair of things
that will be executed “in an arbitrary order”. It is possible
that one order will result in something sensible, whereas the other order
will result in erroneous execution. If the implementation happens to
choose the first order, then the execution is not erroneous. This may
seem odd, but it is not harmful.
Saying that something is erroneous is semantically
equivalent to saying that the behavior is unspecified. However, “erroneous”
has a slightly more disapproving flavor.
Implementation Permissions
[
An implementation
may provide
nonstandard modes of operation. Typically these modes
would be selected by a
pragma
or by a command line switch when the compiler is invoked. When operating
in a nonstandard mode, the implementation may reject
compilation_units
that do not conform to additional requirements associated with the mode,
such as an excessive number of warnings or violation of coding style
guidelines. Similarly, in a nonstandard mode, the implementation may
apply special optimizations or alternative algorithms that are only meaningful
for programs that satisfy certain criteria specified by the implementation.
In any case, an implementation
shall support a
standard mode that conforms to the requirements
of this Reference Manual; in particular, in the standard mode, all legal
compilation_units
shall be accepted.]
Discussion: These permissions are designed
to authorize explicitly the support for alternative modes. Of course,
nothing we say can prevent them anyway, but this (redundant) paragraph
is designed to indicate that such alternative modes are in some sense
“approved” and even encouraged where they serve the specialized
needs of a given user community, so long as the standard mode, designed
to foster maximum portability, is always available.
Implementation Advice
If an implementation detects a bounded error or erroneous
execution, it should raise Program_Error.
Implementation Advice: If a bounded error
or erroneous execution is detected, Program_Error should be raised.
Wording Changes from Ada 83
Some situations that are erroneous in Ada 83
are no longer errors at all. For example, depending on the parameter
passing mechanism when unspecified is possibly nonportable, but not erroneous.
Other situations that are erroneous in Ada 83
are changed to be bounded errors. In particular, evaluating an uninitialized
scalar variable is a bounded error. The possible results are to raise
Program_Error (as always), or to produce a machine-representable value
(which might not be in the subtype of the variable). Violating a Range_Check
or Overflow_Check raises Constraint_Error, even if the value came from
an uninitialized variable. This means that optimizers can no longer “assume”
that all variables are initialized within their subtype's range. Violating
a check that is suppressed remains erroneous.
The “incorrect order dependences”
category of errors is removed. All such situations are simply considered
potential nonportabilities. This category was removed due to the difficulty
of defining what it means for two executions to have a “different
effect”. For example, if a function with a side effect is called
twice in a single expression, it is not in principle possible for the
compiler to decide whether the correctness of the resulting program depends
on the order of execution of the two function calls. A compile time warning
might be appropriate, but raising of Program_Error at run time would
not be.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
