Re: contracted exceptions

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 09 Jun 2007 14:04:23 -0400, Robert A Duff wrote:
>
>> I can think of lots of rules that are not perfect, but are at least
>> superior to the existing rule of silently ignoring the exception.
>> 
>> The simplest would be to terminate the entire program immediately.
>> And print an error message on systems where that makes sense.
>> Ada has no way to terminate the whole program (i.e. call "exit"),
>> but it should.
>
> Terminate the parent task and that should become equivalent to "exit".

Only if the parent task is the environment task.

>> Or just print an error message.
>> 
>> Or raise Program_Error in the parent task at the point where that task
>> awaits its dependents.  Option: abort all the siblings as well.
>> 
>> Or put the task to sleep, so the parent waits forever (and the
>> programmer has to debug a "deadlock").
>
> Maybe a sort of rendezvous on the predefined entry point with the parent
> task?

Maybe.  Will you let me define entries of the environment task?  ;-)

>... When the parent task accepts it, the exception is propagated out of
> the point of rendezvous in the parent, while the offending task finally
> rests in peace. When the parent task does not have this entry, then it
> (with all its children) is terminated. The process continues until
> rendezvous accepted or else death of the main task.

Hmm.  I guess the important thing is that the RM should define this
situation (exception propagation reaches the end of the task body) as an
error.  That would encourage implementations to print error messages,
and debuggers to take control in such situations.

Nothing prevents an implementation from printing an error message in
this situation already -- but it's not encouraged by the RM, any more
than encouraging the impl to print an error every time you assign 42 to
a variable.

>> My solution: allow the programmer to declare that certain regions of
>> code cannot run out of memory.  The compiler must reserve enough memory
>> (and if can't, then raise S_E before entering that region).  Of course,
>> what you can do in such a region is implementation dependent.
>
> Contracted exceptions? Let the user declare a subprogram with the contract
> of no Storage_Error. Then the compiler checks that code and if it cannot
> generate it in a way that would reserve all necessary memory before
> entering the body, it would refuse to compile it.

The implementation can always calculate (at link time) a worst-case
amount of stack space that might be needed.  The worst case might be the
size of the address space in some cases (recursion, X:String:=..., etc).
But the implementation cannot know statically whether that space will
be available at run time, unless the entire program has that property
(see SPARK).

- Bob