Re: contracted exceptions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 09 Jun 2007 16:43:08 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> 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?  ;-)

No, but you can always design it as:

env task
   appl. Ada root task
      all other children

>>... 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.

Printing messages is not enough. One would like to be able to handle this
within the program. BTW, if task were a controlled type, you know... (:-))

>>> 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

and "no Storage_Error" contract could be an easy way to have this property
on subprogram basis. It does not say that Storage_Error will not be
propagated at a call point. It says that it will not if the caller has no
Storage_Error in its contract as well.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de