Re: tasks and protected types

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

"Egil H. H�vik" <egil.harald.hoevikNOSPAM@REMOVEkongsberg.com> writes:

> >
> > RM 9.5.2(26):
> > ...
> > When an exception is propagated from the handled_sequence_of_statements of
> > an accept_statement,
> > the same exception is also raised by the execution of the corresponding
> > entry_call statement.
> >
> >
> > Which means that D1.Start raises an exception, D2.Start is never called,
> and
> > Manage will wait for D2 to terminate
> > (D1 will terminate due to the unhandled exception)

That's right.

> ... and as an accept_statement contains a handled_sequence_of_statements,
> you can
> add the exception handler in the accept statement directly, thus:
> 
> accept Start( Str : in String; Tm : in Positive) do
>    Msg := Str;
>    Times := Tm;
> exception
>    when others =>
>       Ada.Text_IO.Put_Line("Exception caugth in accept statement");
> end Start;

That's not a good idea.  The exception we're talking about here is a
*bug*.  There's no way the task can recover from it.  In the original
example, if you added the above exception handler, the very next thing
the task will do is look at Times, which is an uninitialized variable!

If you want to print a message, follow it by "raise;" or something.

Unfortunately, that doesn't work at the end of a task body.
You can call the C 'exit' routine, or you 'abort' things,
or whatever, but an unhandled exception in a task body causes
it to terminate -- in most implementations, to *silently* terminate.
And then the rest of the system usually hangs.

Alternatively, you can debug this in a debugger.  Tell it to break on
all exceptions, and it will stop at the point of "Msg := Str;",
and then you can figure out what's going on.

- Bob