Re: ISO/IEC 14519 - Ada POSIX binding

["Robert I. Eachus" <rieachus@attbi.com>]

tmoran@acm.org wrote:

>                                                    There is an exception
> Posix.Posix_Error to force the program not to ignore problems.  The
> program must then get the particular error code and figure out what to do.
> I suppose that might translate into "when others =>" in a case statement
> in old code, but it would be a bad programmer indeed who decided "There's
> an error.  I don't understand it.  I'll just pretend I didn't notice it".

Right, while in C, the normal situation is to ignore the possibility 
that an error code will be returned.  With the Posix binding, an Ada 
exception is raised, so it will find an exeception handler (or terminate 
the task silently).  A programmer can still "ignore" the error, it is 
just a lot more visible if they do.  (when others => null;)

Oh, and I have been asked many times why tasks disappear silently if an 
exception occurs after elaboration.  This is one of those things that 
falls in the third part of the standard.  (What happens if you try to 
shoot yourself in the foot.) You are not required to have an exception 
handler in a task body.  But if there is the remotest chance of an 
exception reaching a handler, the handler should be there. Even if it 
just prints an error message. So why isn't it required?

Because there are several tasking idioms, and the right place for the 
catchall error handler differs. For example:

task body Foo is
   ...;
begin
   loop
     begin
       accept ...;
       ...
     exception
       ...
     end;
   end loop;
end Foo;

Requiring an exception handler outside the loop would be silly.  Not 
having an execption handler inside the loop is also silly.  Another example:

task body Bar is
begin

   declare
   ...
   begin
     accept ...;
     ...
   exception
     ...
   end;

end Bar;

Here the author of the task body decided to encapsulate everything 
inside a declare block, either so that elaborating the declarations 
happens as part of the task, not its creator, or so that execptions 
occuring in the declarations are handled inside the task.  In either 
case requiring another exception handler for the task body as a whole 
would just be a pain.