Contents Index Previous Next
11.1 Exception Declarations
1
{exception} An
exception_declaration declares a
name for an exception.
Syntax
2
exception_declaration
::= defining_identifier_list :
exception;
Static Semantics
3
Each single exception_declaration
declares a name for a different exception. If a generic unit includes
an exception_declaration, the exception_declarations
implicitly generated by different instantiations of the generic unit
refer to distinct exceptions (but all have the same defining_identifier).
The particular exception denoted by an exception name is determined at
compilation time and is the same regardless of how many times the exception_declaration
is elaborated.
3.a
Reason: We considered removing
this requirement inside generic bodies, because it is an implementation
burden for implementations that wish to share code among several instances.
In the end, it was decided that it would introduce too much implementation
dependence.
3.b
Ramification: Hence, if
an exception_declaration occurs
in a recursive subprogram, the exception name denotes the same exception
for all invocations of the recursive subprogram. The reason for this
rule is that we allow an exception occurrence to propagate out of its
declaration's innermost containing master; if exceptions were created
by their declarations like other entities, they would presumably be destroyed
upon leaving the master; we would have to do something special to prevent
them from propagating to places where they no longer exist.
3.c
Ramification: Exception
identities are unique across all partitions of a program.
4
{predefined exception}
{Constraint_Error (raised by failure
of run-time check)} {Program_Error
(raised by failure of run-time check)} {Storage_Error
(raised by failure of run-time check)} {Tasking_Error
(raised by failure of run-time check)} The
predefined exceptions are the ones declared in the declaration
of package Standard: Constraint_Error, Program_Error, Storage_Error,
and Tasking_Error[; one of them is raised when a language-defined check
fails.]
4.a
Ramification: The exceptions
declared in the language-defined package IO_Exceptions, for example,
are not predefined.
Dynamic Semantics
5
{elaboration (exception_declaration)
[partial]} The elaboration of an
exception_declaration
has no effect.
6
{Storage_Check [partial]}
{check, language-defined (Storage_Check)}
{Storage_Error (raised by failure
of run-time check)} The execution of any
construct raises Storage_Error if there is insufficient storage for that
execution.
{unspecified [partial]} The
amount of storage needed for the execution of constructs is unspecified.
6.a
Ramification: Note that
any execution whatsoever can raise Storage_Error. This allows much implementation
freedom in storage management.
Examples
7
Examples of user-defined
exception declarations:
8
Singular : exception;
Error : exception;
Overflow, Underflow : exception;
Inconsistencies With Ada 83
8.a
{inconsistencies with Ada 83}
The exception Numeric_Error is now defined in the
Obsolescent features Annex, as a rename of Constraint_Error. All checks
that raise Numeric_Error in Ada 83 instead raise Constraint_Error in
Ada 95. To increase upward compatibility, we also changed the rules to
allow the same exception to be named more than once by a given handler.
Thus, ``when Constraint_Error | Numeric_Error =>'' will remain
legal in Ada 95, even though Constraint_Error and Numeric_Error now denote
the same exception. However, it will not be legal to have separate handlers
for Constraint_Error and Numeric_Error. This change is inconsistent in
the rare case that an existing program explicitly raises Numeric_Error
at a point where there is a handler for Constraint_Error; the exception
will now be caught by that handler.
Wording Changes from Ada 83
8.b
We explicitly define elaboration
for exception_declarations.
Contents Index Previous Next Legal