Re: I/O - exception handling

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

Randy Brukardt wrote:

> It wouldn't be *expected*, but the standard *allows* it, so the truly
> paranoid programmer would have to take that into account. And even if
> you defined it not to raise any IO_Exceptions, it still could raise
> Storage_Error or Program_Error, so you can't claim that it never, ever
> raised any exceptions anyway.
> 
> As I said, its not worth worrying about; in practice, it won't raise an
> exception, and there is no need to protect it. But you can't determine
> that from the standard (and there is no possible standard language from
> which you could).

At the risk of being repitious there are cases in Ada where unusual 
behavior can be associated with particular file types.  A good example I 
ran into years ago was an OS where opening a pipe required a special 
call that returned two file descriptors, and only the first (the write 
end) could be closed, which closed the whole pipe.  An excellent example 
of where a call to Close should raise Use_Error.  But notice that 
opening the pipe took a non-standard Open call.

Another example as I said was that on systems where closing Standard_XXX 
is not allowed, Close should raise Use_Error--if you can somehow get 
ahold of a copy of the (Ada) file object for those files. Notice that 
Close takes an in out File_Type, so the Standard_XXX or Current_XXX 
calls cannot be used as a parameter.  (A user could use the forms which 
return File_Access, and play some games to convert from File_Access 
which is access constant File_Type, then call Close on the result--and 
get what he or she deserves. ;-)

The Ada culture is to ignore these cases--unless you are the user in 
question.  Then you had better look for all sorts of "unexpected" 
exceptions resulting from your use of Unchecked_Conversion or whatever.