Programmer's ROM - The Computer Language Library

home *** CD-ROM | disk | FTP | other *** search

/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / lrm / chap11.doc < prev next >

Wrap

Text File | 1988-05-03 | 37.5 KB | 1,586 lines

The following document is a draft of the corresponding chapter of the version of the Ada Reference Manual produced in response to the Ansi Canvass. It is given a limited circulation to Ada implementers and to other groups contributing comments (according to the conventions defined in RRM.comments). This draft should not be referred to in any publication. ANSI-RM-11-v23 - Draft Chapter 11 Exceptions version 23 83-02-11 This version has addressed all comments up to number #5795 11. Exceptions This chapter defines the facilities for dealing with errors or other exceptional situations that arise during program execution. Such a situation is called an exception. To raise an exception is to abandon normal program execution so as to draw attention to the fact that the corresponding situation has arisen. Executing some actions, in response to the arising of an exception, is called handling the exception. An exception declaration declares a name for an exception. An exception can be raised by a raise statement, or it can be raised by another statement or operation that propagates the exception. When an exception arises, control can be transferred to a user-provided exception handler at the end of a block statement or at the end of the body of a subprogram, package, or task unit. References: block statement 5.6, error situation 1.6, exception handler 11.2, name 4.1, package body 7.1, propagation of an exception 11.4.1 11.4.2, raise statement 11.3, subprogram body 6.3, task body 9.1 11.1 Exception Declarations An exception declaration declares a name for an exception. The name of an exception can only be used in raise statements, exception handlers, and renaming declarations. exception_declaration ::= identifier_list : exception; An exception declaration with several identifiers is equivalent to a sequence of single exception declarations, as explained in section 3.2. Each single exception declaration declares a name for a different exception. In particular, 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 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. 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 following exceptions are predefined in the language; they are raised when the situations described are detected. 11 - 1 CONSTRAINT_ERROR This exception is raised in any of the following situations: upon an attempt to violate a range constraint, an index constraint, or a discriminant constraint; upon an attempt to use a record component that does not exist for the current discriminant values; and upon an attempt to use a selected component, an indexed component, a slice, or an attribute, of an object designated by an access value, if the object does not exist because the access value is null. 11 - 2 NUMERIC_ERROR This exception is raised by the execution of a predefined numeric operation that cannot deliver a correct result (within the declared accuracy for real types); this includes the case where an implementation uses a predefined numeric operation for the execution, evaluation, or elaboration of some construct. The rules given in section 4.5.7 define the cases in which an implementation is not required to raise this exception when such an error situation arises; see also section 11.6. PROGRAM_ERROR This exception is raised upon an attempt to call a subprogram, to activate a task, or to elaborate a generic instantiation, if the body of the corresponding unit has not yet been elaborated. This exception is also raised if the end of a function is reached (see 6.5); or during the execution of a selective wait that has no else part, if this execution determines that all alternatives are closed (see 9.7.1). Finally, depending on the implementation, this exception may be raised upon an attempt to execute an action that is erroneous, and for incorrect order dependences (see 1.6). STORAGE_ERROR This exception is raised in any of the following situations: when the dynamic storage allocated to a task is exceeded; during the evaluation of an allocator, if the space available for the collection of allocated objects is exhausted; or during the elaboration of a declarative item, or during the execution of a subprogram call, if storage is not sufficient. TASKING_ERROR This exception is raised when exceptions arise during intertask communication (see 9 and 11.5). Note: The situations described above can arise without raising the corresponding exceptions, if the pragma SUPPRESS has been used to give permission to omit the corresponding checks (see 11.7). Examples of user-defined exception declarations: SINGULAR : exception; ERROR : exception; OVERFLOW, UNDERFLOW : exception; References: access value 3.8, collection 3.8, declaration 3.1, exception 11, exception handler 11.2, generic body 12.2, generic instantiation 12.3, generic unit 12, identifier 2.3, implicit declaration 12.3, instantiation 12.3, name 4.1, object 3.2, raise statement 11.3, real type 3.5.6, record component 3.7, return statement 5.8, subprogram 6, subprogram body 6.3, task 9, task body 9.1 Constraint_error exception contexts: aggregate 4.3.1 4.3.2, allocator 4.8, assignment statement 5.2 5.2.1, constraint 3.3.2, discrete type attribute 11 - 3 3.5.5, discriminant constraint 3.7.2, elaboration of a generic formal parameter 12.3.1 12.3.2 12.3.4 12.3.5, entry index 9.5, exponentiating operator 4.5.6, index constraint 3.6.1, indexed component 4.1.1, logical operator 4.5.1, null access value 3.8, object declaration 3.2.1, parameter association 6.4.1, qualified expression 4.7, range constraint 3.5, selected component 4.1.3, slice 4.1.2, subtype indication 3.3.2, type conversion 4.6 Numeric_error exception contexts: discrete type attribute 3.5.5, implicit conversion 3.5.4 3.5.6 4.6, numeric operation 3.5.5 3.5.8 3.5.10, operator of a numeric type 4.5 4.5.7 Program_error exception contexts: collection 3.8, elaboration 3.9, elaboration check 3.9 7.3 9.3 12.2, erroneous 1.6, incorrect order dependence 1.6, leaving a function 6.5, selective wait 9.7.1 11 - 4 Storage_error exception contexts: allocator 4.8 Tasking error exception contexts: abort statement 9.10, entry call 9.5 9.7.2 9.7.3, exceptions during task communication 11.5, task activation 9.3 11.2 Exception Handlers The response to one or more exceptions is specified by an exception handler. exception_handler ::= when exception_choice {| exception_choice} => sequence_of_statements exception_choice ::= exception_name | others An exception handler occurs in a construct that is either a block statement or the body of a subprogram, package, task unit, or generic unit. Such a construct will be called a frame in this chapter. In each case the syntax of a frame that has exception handlers includes the following part: begin sequence_of_statements exception exception_handler {exception_handler} end The exceptions denoted by the exception names given as exception choices of a frame must all be distinct. The exception choice others is only allowed for the last exception handler of a frame and as its only exception choice; it stands for all exceptions not listed in previous handlers of the frame, including exceptions whose names are not visible at the place of the exception handler. The exception handlers of a frame handle exceptions that are raised by the execution of the sequence of statements of the frame. The exceptions handled by a given exception handler are those named by the corresponding exception choices. Example: begin -- sequence of statements exception when SINGULAR | NUMERIC_ERROR => PUT(" MATRIX IS SINGULAR "); when others => PUT(" FATAL ERROR "); raise ERROR; end; 11 - 5 Note: The same kinds of statement are allowed in the sequence of statements of each exception handler as are allowed in the sequence of statements of the frame. For example, a return statement is allowed in a handler within a function body. 11 - 6 References: block statement 5.6, declarative part 3.9, exception 11, exception handling 11.4, function body 6.3, generic body 12.2, generic unit 12.1, name 4.1, package body 7.1, raise statement 11.3, return statement 5.8, sequence of statements 5.1, statement 5, subprogram body 6.3, task body 9.1, task unit 9 9.1, visibility 8.3 11.3 Raise Statements A raise statement raises an exception. raise_statement ::= raise [exception_name]; For the execution of a raise statement with an exception name, the named exception is raised. A raise statement without an exception name is only allowed within an exception handler (but not within the sequence of statements of a subprogram, package, task unit, or generic unit, enclosed by the handler); it raises again the exception that caused transfer to the innermost enclosing handler. Examples: raise SINGULAR; raise NUMERIC_ERROR; -- explicitly raising a predefined exception raise; -- only within an exception handler References: exception 11, generic unit 12, name 4.1, package 7, sequence of statements 5.1, subprogram 6, task unit 9 11.4 Exception Handling When an exception is raised, normal program execution is abandoned and control is transferred to an exception handler. The selection of this handler depends on whether the exception is raised during the execution of statements or during the elaboration of declarations. References: declaration 3.1, elaboration 3.1 3.9, exception 11, exception handler 11.2, raising of exceptions 11.3, statement 5 11.4.1 Exceptions Raised During the Execution of Statements 11 - 7 The handling of an exception raised by the execution of a sequence of statements depends on whether the innermost frame or accept statement that encloses the sequence of statements is a frame or an accept statement. The case where an accept statement is innermost is described in section 11.5. The case where a frame is innermost is presented here. 11 - 8 Different actions take place, depending on whether or not this frame has a handler for the exception, and on whether the exception is raised in the sequence of statements of the frame or in that of an exception handler. If an exception is raised in the sequence of statements of a frame that has a handler for the exception, execution of the sequence of statements of the frame is abandoned and control is transferred to the exception handler. The execution of the sequence of statements of the handler completes the execution of the frame (or its elaboration if the frame is a package body). If an exception is raised in the sequence of statements of a frame that does not have a handler for the exception, execution of this sequence of statements is abandoned. The next action depends on the nature of the frame: (a) For a subprogram body, the same exception is raised again at the point of call of the subprogram, unless the subprogram is the main program itself, in which case execution of the main program is abandoned. (b) For a block statement, the same exception is raised again immediately after the block statement (that is, within the innermost enclosing frame or accept statement). (c) For a package body that is a declarative item, the same exception is raised again immediately after this declarative item (within the enclosing declarative part). If the package body is that of a subunit, the exception is raised again at the place of the corresponding body stub. If the package is a library unit, execution of the main program is abandoned. (d) For a task body, the task becomes completed. An exception that is raised again (as in the above cases (a), (b), and (c)) is said to be propagated, either by the execution of the subprogram, the execution of the block statement, or the elaboration of the package body. No propagation takes place in the case of a task body. If the frame is a subprogram or a block statement and if it has dependent tasks, the propagation of an exception takes place only after termination of the dependent tasks. Finally, if an exception is raised in the sequence of statements of an exception handler, execution of this sequence of statements is abandoned. Subsequent actions (including propagation, if any) are as in the cases (a) to (d) above, depending on the nature of the frame. Example: function FACTORIAL (N : POSITIVE) return FLOAT is begin if N = 1 then return 1.0; else return FLOAT(N) * FACTORIAL(N-1); end if; exception 11 - 9 when NUMERIC_ERROR => return FLOAT'SAFE_LARGE; end FACTORIAL; If the multiplication raises NUMERIC_ERROR, then FLOAT'SAFE_LARGE is returned by the handler. This value will cause further NUMERIC_ERROR exceptions to be raised by the evaluation of the expression in each of the remaining invocations of the function, so that for large values of N the function will ultimately return the value FLOAT'SAFE_LARGE. 11 - 10 Example: procedure P is ERROR : exception; procedure R; procedure Q is begin R; ... -- error situation (2) exception ... when ERROR => -- handler E2 ... end Q; procedure R is begin ... -- error situation (3) end R; begin ... -- error situation (1) Q; ... exception ... when ERROR => -- handler E1 ... end P; The following situations can arise: (1) If the exception ERROR is raised in the sequence of statements of the outer procedure P, the handler E1 provided within P is used to complete the execution of P. (2) If the exception ERROR is raised in the sequence of statements of Q, the handler E2 provided within Q is used to complete the execution of Q. Control will be returned to the point of call of Q upon completion of the handler. (3) If the exception ERROR is raised in the body of R, called by Q, the execution of R is abandoned and the same exception is raised in the body of Q. The handler E2 is then used to complete the execution of Q, as in situation (2). Note that in the third situation, the exception raised in R results in (indirectly) transferring control to a handler that is part of Q and hence not enclosed by R. Note also that if a handler were provided within R for the exception choice others, situation (3) would cause execution of this handler, rather than direct termination of R. 11 - 11 Lastly, if ERROR had been declared in R, rather than in P, the handlers E1 and E2 could not provide an explicit handler for ERROR since this identifier would not be visible within the bodies of P and Q. In situation (3), the exception could however be handled in Q by providing a handler for the exception choice others. 11 - 12 Notes: The language does not define what happens when the execution of the main program is abandoned after an unhandled exception. The predefined exceptions are those that can be propagated by the basic operations and the predefined operators. The case of a frame that is a generic unit is already covered by the rules for subprogram and package bodies, since the sequence of statements of such a frame is not executed but is the template for the corresponding sequences of statements of the subprograms or packages obtained by generic instantiation. References: accept statement 9.5, basic operation 3.3.3, block statement 5.6, body stub 10.2, completion 9.4, declarative item 3.9, declarative part 3.9, dependent task 9.4, elaboration 3.1 3.9, exception 11, exception handler 11.2, frame 11.2, generic instantiation 12.3, generic unit 12, library unit 10.1, main program 10.1, numeric_error exception 11.1, package 7, package body 7.1, predefined operator 4.5, procedure 6.1, sequence of statements 5.1, statement 5, subprogram 6, subprogram body 6.3, subprogram call 6.4, subunit 10.2, task 9, task body 9.1 11.4.2 Exceptions Raised During the Elaboration of Declarations If an exception is raised during the elaboration of the declarative part of a given frame, this elaboration is abandoned. The next action depends on the nature of the frame: (a) For a subprogram body, the same exception is raised again at the point of call of the subprogram, unless the subprogram is the main program itself, in which case execution of the main program is abandoned. (b) For a block statement, the same exception is raised again immediately after the block statement. (c) For a package body that is a declarative item, the same exception is raised again immediately after this declarative item, in the enclosing declarative part. If the package body is that of a subunit, the exception is raised again at the place of the corresponding body stub. If the package is a library unit, execution of the main program is abandoned. (d) For a task body, the task becomes completed, and the exception TASKING_ERROR is raised at the point of activation of the task, as explained in section 9.3. Similarly, if an exception is raised during the elaboration of either a package declaration or a task declaration, this elaboration is abandoned; the next action depends on the nature of the declaration. 11 - 13 (e) For a package declaration or a task declaration, that is a declarative item, the exception is raised again immediately after the declarative item in the enclosing declarative part or package specification. For the declaration of a library package, the execution of the main program is abandoned. An exception that is raised again (as in the above cases (a), (b), (c) and (e)) is said to be propagated, either by the execution of the subprogram or block statement, or by the elaboration of the package declaration, task declaration or package body. 11 - 14 Example of an exception in the declarative part of a block statement (case (b)): procedure P is ... begin declare N : INTEGER := F; -- the function F may raise ERROR begin ... exception when ERROR => -- handler E1 end; ... exception when ERROR => -- handler E2 end P; -- if the exception ERROR is raised in the declaration of N, it is handled by E2 References: activation 9.3, block statement 5.6, body stub 10.2, completed task 9.4, declarative item 3.9, declarative part 3.9, elaboration 3.1 3.9, exception 11, frame 11.2, library unit 10.1, main program 10.1, package body 7.1, package declaration 7.1, package specification 7.1, subprogram 6, subprogram body 6.3, subprogram call 6.4, subunit 10.2, task 9, task body 9.1, task declaration 9.1, tasking_error exception 11.1 11.5 Exceptions Raised During Task Communication An exception can be propagated to a task communicating, or attempting to communicate, with another task. An exception can also be propagated to a calling task if the exception is raised during a rendezvous. When a task calls an entry of another task, the exception TASKING_ERROR is raised in the calling task, at the place of the call, if the called task is completed before accepting the entry call or is already completed at the time of the call. A rendezvous can be completed abnormally in two cases: (a) When an exception is raised within an accept statement, but not handled within an inner frame. In this case, the execution of the accept statement is abandoned and the same exception is raised again immediately after the accept statement within the called task; the exception is also propagated to the calling task at the point of the entry call. (b) When the task containing the accept statement is completed abnormally as the result of an abort statement. In this case, the exception TASKING_ERROR is raised in the calling task at the point of the entry 11 - 15 call. On the other hand, if a task issuing an entry call becomes abnormal (as the result of an abort statement) no exception is raised in the called task. If the rendezvous has not yet started, the entry call is cancelled. If the rendezvous is in progress, it completes normally, and the called task is unaffected. 11 - 16 References: abnormal task 9.10, abort statement 9.10, accept statement 9.5, completed task 9.4, entry call 9.5, exception 11, frame 11.2, rendezvous 9.5, task 9, task termination 9.4, tasking_error exception 11.1 11.6 Exceptions and Optimization The purpose of this section is to specify the conditions under which an implementation is allowed to perform certain actions either earlier or later than specified by other rules of the language. In general, when the language rules specify an order for certain actions (the canonical order), an implementation may only use an alternative order if it can guarantee that the effect of the program is not changed by the reordering. In particular, no exception should arise for the execution of the reordered program if none arises for the execution of the program in the canonical order. When, on the other hand, the order of certain actions is not defined by the language, any order can be used by the implementation. (For example, the arguments of a predefined operator can be evaluated in any order since the rules given in section 4.5 do not require a specific order of evaluation.) Additional freedom is left to an implementation for reordering actions involving predefined operations that are either predefined operators or basic operations other than assignments. This freedom is left, as defined below, even in the case where the execution of these predefined operations may propagate a (predefined) exception: (a) For the purpose of establishing whether the same effect is obtained by the execution of certain actions in the canonical and in an alternative order, it can be assumed that none of the predefined operations invoked by these actions propagates a (predefined) exception, provided that the two following requirements are met by the alternative order: first, an operation must not be invoked in the alternative order if it is not invoked in the canonical order; second, for each operation, the innermost enclosing frame or accept statement must be the same in the alternative order as in the canonical order, and the same exception handlers must apply. (b) Within an expression, the association of operators with operands is specified by the syntax. However, for a sequence of predefined operators of the same precedence level (and in the absence of parentheses imposing a specific association), any association of operators with operands is allowed if it satisfies the following requirement: an integer result must be equal to that given by the canonical left-to-right order; a real result must belong to the result model interval defined for the canonical left-to-right order (see 4.5.7). Such a reordering is allowed even if it may remove an exception, or introduce a further predefined exception. Similarly, additional freedom is left to an implementation for the evaluation of numeric simple expressions. For the evaluation of a 11 - 17 predefined operation, an implementation is allowed to use the operation of a type that has a range wider than that of the base type of the operands, provided that this delivers the exact result (or a result within the declared accuracy, in the case of a real type), even if some intermediate results lie outside the range of the base type. The exception NUMERIC_ERROR need not be raised in such a case. In particular, if the numeric expression is an operand of a predefined relational operator, the exception NUMERIC_ERROR need not be raised by the evaluation of the relation, provided that the correct BOOLEAN result is obtained. 11 - 18 A predefined operation need not be invoked at all, if its only possible effect is to propagate a predefined exception. Similarly, a predefined operation need not be invoked if the removal of subsequent operations by the above rule renders this invocation ineffective. Notes: Rule (b) applies to predefined operators but not to the short-circuit control forms. The expression SPEED < 300_000.0 can be replaced by TRUE if the value 300_000.0 lies outside the base type of SPEED, even though the implicit conversion of the numeric literal would raise the exception NUMERIC_ERROR. Example: declare N : INTEGER; begin N := 0; -- (1) for J in 1 .. 10 loop N := N + J**A(K); -- A and K are global variables end loop; PUT(N); exception when others => PUT("Some error arose"); PUT(N); end; The evaluation of A(K) may be performed before the loop, and possibly immediately before the assignment statement (1) even if this evaluation can raise an exception. Consequently, within the exception handler, the value of N is either the undefined initial value or a value later assigned. On the other hand, the evaluation of A(K) cannot be moved before begin since an exception would then be handled by a different handler. For this reason, the initialization of N in the declaration itself would exclude the possibility of having an undefined initial value of N in the handler. References: accept statement 9.5, accuracy of real operations 4.5.7, assignment 5.2, base type 3.3, basic operation 3.3.3, conversion 4.6, error situation 11, exception 11, exception handler 11.2, frame 11.2, numeric_error exception 11.1, predefined operator 4.5, predefined subprogram 8.6, propagation of an exception 11.4, real type 3.5.6, undefined value 3.2.1 11.7 Suppressing Checks The presence of a SUPPRESS pragma gives permission to an implementation to omit certain run-time checks. The form of this pragma is as follows: pragma SUPPRESS(identifier [, [ON =>] name]); 11 - 19 The identifier is that of the check that can be omitted. The name (if present) must be either a simple name or an expanded name and it must denote either an object, a type or subtype, a task unit, or a generic unit; alternatively the name can be a subprogram name, in which case it can stand for several visible overloaded subprograms. 11 - 20 A pragma SUPPRESS is only allowed immediately within a declarative part or immediately within a package specification. In the latter case, the only allowed form is with a name that denotes an entity (or several overloaded subprograms) declared immediately within the package specification. The permission to omit the given check extends from the place of the pragma to the end of the declarative region associated with the innermost enclosing block statement or program unit. For a pragma given in a package specification, the permission extends to the end of the scope of the named entity. If the pragma includes a name, the permission to omit the given check is further restricted: it is given only for operations on the named object or on all objects of the base type of a named type or subtype; for calls of a named subprogram; for activations of tasks of the named task type; or for instantiations of the given generic unit. The following checks correspond to situations in which the exception CONSTRAINT_ERROR may be raised; for these checks, the name (if present) must denote either an object or a type. ACCESS_CHECK When accessing a selected component, an indexed component, a slice, or an attribute, of an object designated by an access value, check that the access value is not null. DISCRIMINANT_CHECK Check that a discriminant of a composite value has the value imposed by a discriminant constraint. Also, when accessing a record component, check that it exists for the current discriminant values. INDEX_CHECK Check that the bounds of an array value are equal to the corresponding bounds of an index constraint. Also, when accessing a component of an array object, check for each dimension that the given index value belongs to the range defined by the bounds of the array object. Also, when accessing a slice of an array object, check that the given discrete range is compatible with the range defined by the bounds of the array object. LENGTH_CHECK Check that there is a matching component for each component of an array, in the case of array assignments, type conversions, and logical operators for arrays of boolean components. RANGE_CHECK Check that a value satisfies a range constraint. Also, for the elaboration of a subtype indication, check that the constraint (if present) is compatible with the type mark. Also, for an aggregate, check that an index or discriminant value belongs to the corresponding subtype. Finally, check for any constraint checks performed by a generic instantiation. 11 - 21 The following checks correspond to situations in which the exception NUMERIC_ERROR is raised. The only allowed names in the corresponding pragmas are names of numeric types. DIVISION_CHECK Check that the second operand is not zero for the operations /, rem and mod. OVERFLOW_CHECK Check that the result of a numeric operation does not overflow. The following check corresponds to situations in which the exception PROGRAM_ERROR is raised. The only allowed names in the corresponding pragmas are names denoting task units, generic units, or subprograms. ELABORATION_CHECK When either a subprogram is called, a task activation is accomplished, or a generic instantiation is elaborated, check that the body of the corresponding unit has already been elaborated. 11 - 22 The following check corresponds to situations in which the exception STORAGE_ERROR is raised. The only allowed names in the corresponding pragmas are names denoting access types, task units, or subprograms. STORAGE_CHECK Check that execution of an allocator does not require more space than is available for a collection. Check that the space available for a task or subprogram has not been exceeded. If an error situation arises in the absence of the corresponding run-time checks, the execution of the program is erroneous (the results are not defined by the language). Examples: pragma SUPPRESS(RANGE_CHECK); pragma SUPPRESS(INDEX_CHECK, ON => TABLE); Notes: For certain implementations, it may be impossible or too costly to suppress certain checks. The corresponding SUPPRESS pragma can be ignored. Hence, the occurrence of such a pragma within a given unit does not guarantee that the corresponding exception will not arise; the exceptions may also be propagated by called units. References: access type 3.8, access value 3.8, activation 9.3, aggregate 4.3, allocator 4.8, array 3.6, attribute 4.1.4, block statement 5.6, collection 3.8, compatible 3.3.2, component of an array 3.6, component of a record 3.7, composite type 3.3, constraint 3.3, constraint_error exception 11.1, declarative part 3.9, designate 3.8, dimension 3.6, discrete range 3.6, discriminant 3.7.1, discriminant constraint 3.7.2, elaboration 3.1 3.9, erroneous 1.6, error situation 11, expanded name 4.1.3, generic body 11.1, generic instantiation 12.3, generic unit 12, identifier 2.3, index 3.6, index constraint 3.6.1, indexed component 4.1.1, null access value 3.8, numeric operation 3.5.5 3.5.8 3.5.10, numeric type 3.5, numeric_error exception 11.1, object 3.2, operation 3.3.3, package body 7.1, package specification 7.1, pragma 2.8, program_error exception 11.1, program unit 6, propagation of an exception 11.4, range constraint 3.5, record type 3.7, simple name 4.1, slice 4.1.2, subprogram 6, subprogram body 6.3, subprogram call 6.4, subtype 3.3, subunit 10.2, task 9, task body 9.1, task type 9.1, task unit 9, type 3.3, type mark 3.3.2 11 - 23