Contents Index Previous Next
1.1.5 Classification of Errors
Implementation Requirements
1
The language definition
classifies errors into several different categories:
2
- Errors that are required to be detected prior to run time
by every Ada implementation;
3
These errors correspond to any violation of a rule
given in this International Standard, 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.
4
{compile-time error}
{error (compile-time)}
{link-time error: See post-compilation
error} {error (link-time)}
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.
4.a
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.
5
- Errors that are required to be detected at run time by
the execution of an Ada program;
6
{run-time error} {error
(run-time)} 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.]
7
8
The language rules define certain kinds of errors
that need not be detected either prior to or during run time, but if
not detected, the range of possible effects shall be bounded. {bounded
error} The errors of this category are
called bounded errors. {Program_Error (raised
by failure of run-time check)} 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.
9
10
{erroneous execution}
In addition to bounded errors, the language rules
define certain kinds of errors as leading to erroneous execution.
Like bounded errors, the implementation need not 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.
10.a
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.)
10.b
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.
10.c
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
11
[
{mode of operation (nonstandard)}
{nonstandard mode} 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.
{mode of operation (standard)} {standard
mode} In any case, an implementation shall
support a
standard mode that conforms to the requirements of this
International Standard; in particular, in the standard mode, all legal
compilation_units shall be accepted.]
11.a
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
12
{Program_Error (raised by failure
of run-time check)} If an implementation
detects a bounded error or erroneous execution, it should raise Program_Error.
Wording Changes from Ada 83
12.a
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 non-portable,
but not erroneous.
12.b
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. {Program_Error
(raised by failure of run-time check)} 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). {Constraint_Error
(raised by failure of run-time check)} 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.
12.c
The ``incorrect order dependences''
category of errors is removed. All such situations are simply considered
potential non-portabilities. 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.
Contents Index Previous Next Legal