I/O - exception handling

I/O - exception handling

[Sergey Koshcheyev]

Hi,

I have this problem: I have a simple piece of code opening a file, reading a
few lines, then closing it. Now, I want this piece of code to be "safe",
i.e. not to leak any resources (the open file) in case of errors and not to
propagate any exceptions. What is the best style to write this code?

Currently, I have something like (not compiled):

procedure Read_Something (...) is
   use Ada.Text_IO;
   use Ada.Strings.Unbounded;
   use Ada.Strings.Unbounded.Text_IO;
   --  GNAT-specific package, I believe

   File : File_Type;
   S1, S2 : Unbounded_String;

begin
   Open (File, Name => "test.txt", Mode => In_File);
   Get_Line (File, S1);
   Get_Line (File, S2);
   Close (File);

exception
   when others =>
      if Is_Open (File) then
         begin
            Close (File);
         exception
            --  Close can raise exceptions too!
            when others => null;
         end;
      end if;
end Read_Something;

However, this looks ugly to me, since I have to close the file in two
places, and also guard for exceptions while handling exceptions. Is there a
better solution or is this sort of thing OK in the Ada way?

Sergey.

Re: I/O - exception handling

[Preben Randhol]

Sergey Koshcheyev wrote:
> Hi,
> 
> I have this problem: I have a simple piece of code opening a file, reading a
> few lines, then closing it. Now, I want this piece of code to be "safe",
> i.e. not to leak any resources (the open file) in case of errors and not to
> propagate any exceptions. What is the best style to write this code?

[...]

> begin
>    Open (File, Name => "test.txt", Mode => In_File);
>    Get_Line (File, S1);
>    Get_Line (File, S2);
>    Close (File);
> 
> exception
>    when others =>

In stead of when others => why don't you check which exception
occurred?

You have Name_Error, Use_Error, Device_Error, End_Error etc...

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Sergey Koshcheyev]

> In stead of when others => why don't you check which exception
> occurred?
>
> You have Name_Error, Use_Error, Device_Error, End_Error etc...

For simplicity - currently it's enough for me just to know that something
failed. And besides, I don't think it would solve the problem, even if I
checked for specific exceptions.

Sergey.

Re: I/O - exception handling

[Simon Wright]

Preben Randhol <randhol+abuse@pvv.org> writes:

> In stead of when others => why don't you check which exception
> occurred?
> 
> You have Name_Error, Use_Error, Device_Error, End_Error etc...

Yes, but OP probably did other not-shown stuff which could have raised
any exception ..

Re: I/O - exception handling

[Preben Randhol]

Simon Wright wrote:
> Preben Randhol <randhol+abuse@pvv.org> writes:
> 
>> In stead of when others => why don't you check which exception
>> occurred?
>> 
>> You have Name_Error, Use_Error, Device_Error, End_Error etc...
> 
> Yes, but OP probably did other not-shown stuff which could have raised
> any exception ..

Yes, but say that one of the exceptions where an Contraint error, then
one probably need to close the file as it was not the opening of the
file that failed, while if it was a I/O exception one don't need to
close the file as it wasn't opened.


-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Preben Randhol]

Sergey Koshcheyev wrote:
>> In stead of when others => why don't you check which exception
>> occurred?
>>
>> You have Name_Error, Use_Error, Device_Error, End_Error etc...
> 
> For simplicity - currently it's enough for me just to know that something
> failed. And besides, I don't think it would solve the problem, even if I
> checked for specific exceptions.

Well I don't know what you are doing, but I would have checked so I
could give some feedback as to what the problem is.


I do this check in my application so the user can get propper feedback:


      exception
         when Name_Error =>
            Dialogs.Warning
               (Title   => -"Could not find file",
                Message => -"The file you requested :" & ASCII.LF &
                             ASCII.LF & filename & ASCII.LF & ASCII.LF &
                           (-"Could not be found. Please check that "&
                             "you spelt the filename correctly."),
                Has_Main => True);

         when Use_Error =>
            Dialogs.Warning
               (Title   => -"Could not open file",
                Message => -"The file you requested :" & ASCII.LF &
                             ASCII.LF & filename & ASCII.LF & ASCII.LF &
                           (-"Could not be opened. Please check that "&
                             "you have permission to read this file."),
                Has_Main => True);

         when Device_Error | End_Error =>
            Dialogs.Warning
               (Title   => -"Could not open file",
                Message => -"The file you requested :" & ASCII.LF &
                             ASCII.LF & filename & ASCII.LF & ASCII.LF &
                           (-"Could not be opened. Please check that "&
                             "it is a valid file."),
                Has_Main => True);
         when E : others =>
            Dialogs.Error_Report
               (Error =>
                  (-"An unexpected error occurred while trying to open ") &
                  ASCII.LF & ASCII.LF & filename &
                  ASCII.LF & ASCII.LF & "Please Report this!" &
                  ASCII.LF & ASCII.LF & Exception_Information (E));
      end;

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Preben Randhol]

Preben Randhol wrote:
> Sergey Koshcheyev wrote:
>>> In stead of when others => why don't you check which exception
>>> occurred?
>>>
>>> You have Name_Error, Use_Error, Device_Error, End_Error etc...
>> 
>> For simplicity - currently it's enough for me just to know that something
>> failed. And besides, I don't think it would solve the problem, even if I
>> checked for specific exceptions.
> 
> Well I don't know what you are doing, but I would have checked so I
> could give some feedback as to what the problem is.
> 
> 
> I do this check in my application so the user can get propper feedback:
> 
> 
>       exception
>          when Name_Error =>
>             Dialogs.Warning
>                (Title   => -"Could not find file",
>                 Message => -"The file you requested :" & ASCII.LF &
>                              ASCII.LF & filename & ASCII.LF & ASCII.LF &
>                            (-"Could not be found. Please check that "&
>                              "you spelt the filename correctly."),
>                 Has_Main => True);
> 
>          when Use_Error =>
>             Dialogs.Warning
>                (Title   => -"Could not open file",
>                 Message => -"The file you requested :" & ASCII.LF &
>                              ASCII.LF & filename & ASCII.LF & ASCII.LF &
>                            (-"Could not be opened. Please check that "&
>                              "you have permission to read this file."),
>                 Has_Main => True);
> 
>          when Device_Error | End_Error =>
>             Dialogs.Warning
>                (Title   => -"Could not open file",
>                 Message => -"The file you requested :" & ASCII.LF &
>                              ASCII.LF & filename & ASCII.LF & ASCII.LF &
>                            (-"Could not be opened. Please check that "&
>                              "it is a valid file."),
>                 Has_Main => True);
>          when E : others =>
>             Dialogs.Error_Report
>                (Error =>
>                   (-"An unexpected error occurred while trying to open ") &
>                   ASCII.LF & ASCII.LF & filename &
>                   ASCII.LF & ASCII.LF & "Please Report this!" &
>                   ASCII.LF & ASCII.LF & Exception_Information (E));
>       end;


Actually this is some old code as I rewrote it to use enumerations
later.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Sergey Koshcheyev]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbd494u.523.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Sergey Koshcheyev wrote:
> I do this check in my application so the user can get propper feedback:
>
>       exception
>          when Name_Error =>

<snip>

>       end;

OK, I'll try to explain my problem on your example. You report the error.
Then, where do you close the file you're reading from?
 - If you close it inside the exception block, you leak the file, since it
will not be closed on errors.
 - If you close it outside the exception block, then the problem is that
Close can raise an exception too, and the code gets uglier.
 - If you close it while handling exceptions, the exception you're handling
might have occured while opening the file, and closing a non-open file will
cause another exception.

So, are there any other possibilites, or which of these three is generally
considered the best?

Sergey.

Re: I/O - exception handling

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]


"Sergey Koshcheyev" <serko84@hotmail.com> a �crit dans le message de news:bat3ee$2ec$1@ns.felk.cvut.cz...
[..]
> procedure Read_Something (...) is
>    use Ada.Text_IO;
>    use Ada.Strings.Unbounded;
>    use Ada.Strings.Unbounded.Text_IO;
>    --  GNAT-specific package, I believe
>
>    File : File_Type;
>    S1, S2 : Unbounded_String;
>
> begin
>    Open (File, Name => "test.txt", Mode => In_File);
>    Get_Line (File, S1);
>    Get_Line (File, S2);
>    Close (File);
>
> exception
>    when others =>
>       if Is_Open (File) then
>          begin
>             Close (File);
>          exception
>             --  Close can raise exceptions too!
>             when others => null;
>          end;
>       end if;
> end Read_Something;

Doing so will make the exception disappear. You exception handler should rather read:
 exception
    when others =>
       if Is_Open (File) then
          begin
             Close (File);
          exception
             --  Close can raise exceptions too!
             when others => null;
          end;
       end if;
       raise;   -- Reraise the original exception, even if you had another exception at close
 end Read_Something;

> However, this looks ugly to me, since I have to close the file in two
> places, and also guard for exceptions while handling exceptions. Is there a
> better solution or is this sort of thing OK in the Ada way?
>
> Sergey.
>
>

Re: I/O - exception handling

[Sergey Koshcheyev]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:ln9tab.i6j.ln@skymaster...
> Doing so will make the exception disappear. You exception handler should
rather read:
>  exception

<snip>

>        raise;   -- Reraise the original exception, even if you had another
exception at close
>  end Read_Something;

Yes, let's just say that I handle the exception appropriately. I'm more
concerned with the fact that I have to handle exceptions twice, and close
the file in two places, too.

Sergey.

Re: I/O - exception handling

[Hyman Rosen]

Sergey Koshcheyev wrote:
 > Is there a better solution or is this sort of thing OK in the Ada way?

The C++ way is to declare an object with a destructor (Finalize in Ada)
which holds the File_Type and closes it upon destruction. Since this
happens upon block exit, regardless of how that happens, you only have
to have one Close, and of course, once you have such an object, you can
use it everywhere.

Ada makes it somewhat painful to do this since types with Finalization
have to be declared at library level.

Re: I/O - exception handling

[Sergey Koshcheyev]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:lEqAa.18129$fT5.1702@nwrdny01.gnilink.net...
> The C++ way is to declare an object with a destructor (Finalize in Ada)
> which holds the File_Type and closes it upon destruction. Since this
> happens upon block exit, regardless of how that happens, you only have
> to have one Close, and of course, once you have such an object, you can
> use it everywhere.
>
> Ada makes it somewhat painful to do this since types with Finalization
> have to be declared at library level.

Yes, C++ handles this very nicely, that's why I'm trying to find a better
Ada way. I myself miss constructors and destructors in Ada a lot.

Sergey.

Re: I/O - exception handling

[Steve]

Here's an approach that only uses close once, but it isn't pretty either.

 begin
    begin
       begin
          Open (File, Name => "test.txt", Mode => In_File);
       exception
            when others =>
                null; -- report exception opening file ???
                return;
       end;
       Get_Line (File, S1);
       Get_Line (File, S2);
    exception
       when others =>
           null; -- report exception???
    end;
    Close (File);
 exception
    when others =>
      null; -- report exception ???
 end Read_Something;

Steve
(The Duck)

"Sergey Koshcheyev" <serko84@hotmail.com> wrote in message
news:bat3ee$2ec$1@ns.felk.cvut.cz...
> Hi,
>
> I have this problem: I have a simple piece of code opening a file, reading
a
> few lines, then closing it. Now, I want this piece of code to be "safe",
> i.e. not to leak any resources (the open file) in case of errors and not
to
> propagate any exceptions. What is the best style to write this code?
>
> Currently, I have something like (not compiled):
>
> procedure Read_Something (...) is
>    use Ada.Text_IO;
>    use Ada.Strings.Unbounded;
>    use Ada.Strings.Unbounded.Text_IO;
>    --  GNAT-specific package, I believe
>
>    File : File_Type;
>    S1, S2 : Unbounded_String;
>
> begin
>    Open (File, Name => "test.txt", Mode => In_File);
>    Get_Line (File, S1);
>    Get_Line (File, S2);
>    Close (File);
>
> exception
>    when others =>
>       if Is_Open (File) then
>          begin
>             Close (File);
>          exception
>             --  Close can raise exceptions too!
>             when others => null;
>          end;
>       end if;
> end Read_Something;
>
> However, this looks ugly to me, since I have to close the file in two
> places, and also guard for exceptions while handling exceptions. Is there
a
> better solution or is this sort of thing OK in the Ada way?
>
> Sergey.
>
>

Re: I/O - exception handling

[Preben Randhol]

Sergey Koshcheyev wrote:
> 
> OK, I'll try to explain my problem on your example. You report the error.
> Then, where do you close the file you're reading from?
>  - If you close it inside the exception block, you leak the file, since it
> will not be closed on errors.
>  - If you close it outside the exception block, then the problem is that
> Close can raise an exception too, and the code gets uglier.
>  - If you close it while handling exceptions, the exception you're handling
> might have occured while opening the file, and closing a non-open file will
> cause another exception.
> 
> So, are there any other possibilites, or which of these three is generally
> considered the best?

OK understand. *I* would then do:

   procedure Safe_Close (File : File_Type) 
   is
   begin
      if Is_Open (File) then
         begin
            Close (File);
         exception
            --  Close can raise exceptions too!
            when others => null;
         end;
      end if;
   end Safe_Close;


   procedure One_Of_Your_Procedures_That_Open_Files 
   is
   begin
      Open (File, Name => "test.txt", Mode => In_File);
      Get_Line (File, S1);
      Get_Line (File, S2);

      Safe_Close (File);
   exception
      when others =>
         Safe_Close (File);
   end Read_Something;

Now you can use the Safe_Close in any function you like.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Sergey Koshcheyev]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbd4hqk.2hh.randhol+abuse@kiuk0152.chembio.ntnu.no...
> OK understand. *I* would then do:
>
>    procedure Safe_Close (File : File_Type)
>    is
>    begin
>       if Is_Open (File) then
>          begin
>             Close (File);
>          exception
>             --  Close can raise exceptions too!
>             when others => null;
>          end;
>       end if;
>    end Safe_Close;
>
>
>    procedure One_Of_Your_Procedures_That_Open_Files
>    is
>    begin
>       Open (File, Name => "test.txt", Mode => In_File);
>       Get_Line (File, S1);
>       Get_Line (File, S2);
>
>       Safe_Close (File);

I'd change the line above to just "Close (File);", to have the opportunity
to handle any error raised by Close.

>    exception
>       when others =>
>          Safe_Close (File);
>    end Read_Something;
>
> Now you can use the Safe_Close in any function you like.

I thought of this solution, but here the problem is code duplication. In
this case it doesn't matter, but what if there were several files? You'd
have a procedure Close_All and a procedure Safe_Close_All, which would both
contain similar code.

But I guess the perfect general solution doesn't exist in Ada. By the way,
it seems to exist in C++, which is sort of strange, shouldn't it be the
other way around? ;-) Your solution seems close enough to perfect, however,
so that's probably what I'd use.

Sergey.

Re: I/O - exception handling

[Preben Randhol]

Sergey Koshcheyev wrote:
>>       Safe_Close (File);
> 
> I'd change the line above to just "Close (File);", to have the opportunity
> to handle any error raised by Close.

Sure, I thought you didn't want though.

>> Now you can use the Safe_Close in any function you like.
> 
> I thought of this solution, but here the problem is code duplication. In
> this case it doesn't matter, but what if there were several files? You'd
> have a procedure Close_All and a procedure Safe_Close_All, which would both
> contain similar code.

Please explain, I don't follow you.

> But I guess the perfect general solution doesn't exist in Ada. By the way,
> it seems to exist in C++, which is sort of strange, shouldn't it be the
> other way around? ;-) Your solution seems close enough to perfect, however,
> so that's probably what I'd use.

Well why don't you use Finalize ?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Sergey Koshcheyev]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbd4m0j.4gn.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Sergey Koshcheyev wrote:
> >>       Safe_Close (File);
> >
> > I'd change the line above to just "Close (File);", to have the
opportunity
> > to handle any error raised by Close.
>
> Sure, I thought you didn't want though.

Well, in this case I get error checking for free, so why not :-)

> > I thought of this solution, but here the problem is code duplication. In
> > this case it doesn't matter, but what if there were several files? You'd
> > have a procedure Close_All and a procedure Safe_Close_All, which would
both
> > contain similar code.
>
> Please explain, I don't follow you.

OK, let's imagine I have two files and also want to handle several types of
errors:

procedure Two_Files_IO is
   File1, File2 : File_Type;
begin
   Open (File1);
   Open (File2);

   --  Read from File1 into File2 or something like that

   --  Normal clean-up, error-checked
   Close (File1);
   Close (File2);
exception
   when Some_Error =>
      --  Report
      Safe_Close (File1);
      Safe_Close (File2);

   when Another_Error =>
      --  Report
      Safe_Close (File1);
      Safe_Close (File2);

   when others =>
      --  "Safe" clean-up
      Safe_Close (File1);
      Safe_Close (File2);
end Two_Files_IO;

Now, this is of course extreme. So I'd probably rewrite it as follows:

procedure Two_Files_IO is
...
begin
   begin
      Open (File1); Open (File2);
      --  Read from two files
   exception
      when Some_Error =>
         --  Report
         null;
      when Another_Error =>
         --  Report
         null;
      when others => null;
   end;

   Safe_Close (File1);
   Safe_Close (File2);
end Two_Files_IO;

This is probably going to be my ideal solution, now that I think of it. Here
I have given up the error-checking during the "normal clean-up", but the C++
people do it too, so it's going to be OK with me :-)
Now of course, the fact that Close raises exceptions seems sort of useless,
even unhelpful. What am I supposed to do with a file, if I can't close it?
Hm, maybe I should write my own Sergey.Text_IO :-)

> Well why don't you use Finalize ?

I just find it too restricted to be worth the hassle ("derive from a type",
"declare at a library level", etc., etc. ... why not just "for X'Finalize
use Finalize_X"? - the compiler knows when the objects are to be finalized,
anyway). Besides, it's not my fault that Text_IO.File_Type isn't
Limited_Controlled already. Hm, why stop at Text_IO, maybe I should write an
Ada++? :-) Just kidding...

Anyway, since I have arrived at a solution that pleases me, I think I'll
close this discussion now.

Thanks to all who replied,
Sergey.

Re: I/O - exception handling

[Hyman Rosen]

Sergey Koshcheyev wrote:
> Now of course, the fact that Close raises exceptions seems sort of useless,
> even unhelpful. What am I supposed to do with a file, if I can't close it?

We encounter this in C++ as well. The only thing you can do when close
fails is to notify the user. C++ fstream objects have a close method
which returns an error code if the underlying close fails, and their
destructors just do a close without checking for errors, so you can
have it whichever way you want.

Re: I/O - exception handling

[Hyman Rosen]

Sergey Koshcheyev wrote:
> I myself miss constructors and destructors in Ada a lot.

Well, Ada has them, albeit in an inconvenient form. You need a
type which inherits from Controlled, and that type must be
declared at library level for some safety reason that Ada folks
appreciate.

I don't know if there's a way to use access discriminants in
combination with generics to get a "universal" cleanup object
that could forward to a function. Ada experts?

Re: I/O - exception handling

[Larry Kilgallen]

In article <D7zAa.12988$xV3.9550@nwrdny03.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> Sergey Koshcheyev wrote:
>> Now of course, the fact that Close raises exceptions seems sort of useless,
>> even unhelpful. What am I supposed to do with a file, if I can't close it?
> 
> We encounter this in C++ as well. The only thing you can do when close
> fails is to notify the user. C++ fstream objects have a close method
> which returns an error code if the underlying close fails, and their
> destructors just do a close without checking for errors, so you can
> have it whichever way you want.

I saw a case where a major defect in some software (not Ada or C*)
that would have been detected in a much less disruptive fashion if
only a failure on closing a file had not been ignored.  The person
who programmed it to be ignored thought "the file failing to close
will be immaterial shortly after this anyway" whereas in fact the
failure to close ended up indicating (or not, in this case) some
significant error in overall program logic.

Re: I/O - exception handling

[Anisimkov]

"Sergey Koshcheyev" <serko84@hotmail.com> wrote in message
news:bat3ee$2ec$1@ns.felk.cvut.cz...

> procedure Read_Something (...) is
>    use Ada.Text_IO;
>    use Ada.Strings.Unbounded;
>    use Ada.Strings.Unbounded.Text_IO;
>    --  GNAT-specific package, I believe
>
>    File : File_Type;
>    S1, S2 : Unbounded_String;
>
> begin
>    Open (File, Name => "test.txt", Mode => In_File);
>    Get_Line (File, S1);
>    Get_Line (File, S2);
>    Close (File);
>
> exception
>    when others =>
>       if Is_Open (File) then
>          begin
>             Close (File);
>          exception
>             --  Close can raise exceptions too!
>             when others => null;
>          end;
>       end if;
> end Read_Something;
>
> However, this looks ugly to me, since I have to close the file in two
> places, and also guard for exceptions while handling exceptions. Is there a
> better solution or is this sort of thing OK in the Ada way?

Your should not catch exception on the Close, becouse Ada95 RM A.8.2 File
Management
says "The exception Status_Error is propagated if the given file is not
open.". So if file is Open, you do not need to wait exception. I thing GNAT
spetsific Ada.Strings.Unbounded.Text_IO.Close have the same behavior. If you
are want to catch exception anyway (for example you are using any other IO
implementation.) you can make local procedure inside of Read_Something.

 procedure Read_Something (...) is
    use Ada.Text_IO;
    use Ada.Strings.Unbounded;
    use Ada.Strings.Unbounded.Text_IO;
    --  GNAT-specific package, I believe

    File : File_Type;
    S1, S2 : Unbounded_String;

   procedure Close_File is
   begin
       if Is_Open (File) then
          begin
             Close (File);
          exception
             --  Close can raise exceptions too!
             when others => null;
          end;
       end if;
   end Close_File;

 begin
    Open (File, Name => "test.txt", Mode => In_File);
    Get_Line (File, S1);
    Get_Line (File, S2);
    Close_File;

 exception
    when others =>
         Close_File;
end Read_Something;

But, in my point of view, it is bad practice to suppress exception
completely. I prefer to know about errors in program execution. If we do not
suppress exception, code become simplier. We need to catch exceptions only in
Get_Line routines. Exceptions in Open routine do not need to be catched
becouse we do not need to close not opened file. For the Ada semantic File we
can write just.

 procedure Read_Something (...) is
    use Ada.Text_IO;
    use Ada.Strings.Unbounded;
    use Ada.Strings.Unbounded.Text_IO;
    --  GNAT-specific package, I believe

    File : File_Type;
    S1, S2 : Unbounded_String;


begin
    Open (File, Name => "test.txt", Mode => In_File);
    Get_Line (File, S1);
    Get_Line (File, S2);
    Close (File);

exception
    when Device_Error | Data_Error =>
          --  Device_Error and Data_Error could be raised only on IO
operations
          --  So the file is already opened and we do not need to check is
file open
          --  before close.

          Close_File (File);
          raise;
end Read_Something;

Re: I/O - exception handling

[Hyman Rosen]

The main problem is that when you get an error on closing a
file, there's no recovery possible short of trying to recreate
its contents somehow and somewhere. It's more like a hardware
error than anything else.

Re: I/O - exception handling

[Robert I. Eachus]

Preben Randhol wrote:
> 
> OK understand. *I* would then do:
> 
>    procedure Safe_Close (File : File_Type)...
> 
> Now you can use the Safe_Close in any function you like.

I have "decorated" open and close routines that I keep copying around 
and using in even simple utilities because even the most minimal code to 
  open a file, check that the open succeeded, or print a diagnotic if it 
didn't runs to over a page.  But I haven't considered these things as a 
good candidate for standardization because there are just too many 
different text strings--and personal preferences--involved.

The other problem is that the open routine can't exit from the enclosing 
procedure, so after printing a diagnostic, it has to reraise the 
exception (or raise some other exception).  This is fine if the program 
can't run without an input file, but there are other cases where you 
might want to continue.  Gets complicated, but that is the nature of a 
file that may or may not exist, and may not be accessable due to 
permissions, or may be open by some other program for writing and so on.

The only conclusion I have reached is that there is no such thing as 
"simply" opening a file.

Re: I/O - exception handling

[Sergey Koshcheyev]

Anisimkov wrote:
> "Sergey Koshcheyev" <serko84@hotmail.com> wrote in message
> Your should not catch exception on the Close, becouse Ada95 RM A.8.2 File
> Management
> says "The exception Status_Error is propagated if the given file is not
> open.". So if file is Open, you do not need to wait exception. I thing GNAT
> spetsific Ada.Strings.Unbounded.Text_IO.Close have the same behavior. If you
> are want to catch exception anyway (for example you are using any other IO
> implementation.) you can make local procedure inside of Read_Something.

(The File_Type, Open and Close that were used in my example are from 
Ada.Text_IO, only Get_Line comes from A.S.U.Text_IO, and that's a 
function, not a procedure as I used it originally. But the example was 
only meant to illustrate, I'm sorry for the confusion.)

I've seen the paragraph, but I don't know if it can be read as "the only 
exception that may be propagated from Close is Status_Error, and that 
only if the file was not open" - the clause doesn't give me any such 
guarantees.

For example, I think Close is legally allowed to raise Device_Error, or 
even Use_Error.

>  begin
>     Open (File, Name => "test.txt", Mode => In_File);
>     Get_Line (File, S1);
>     Get_Line (File, S2);
>     Close_File;
> 
>  exception
>     when others =>
>          Close_File;
> end Read_Something;

This closes the file twice, as does the example below - something I 
don't like.

> But, in my point of view, it is bad practice to suppress exception
> completely. I prefer to know about errors in program execution. If we do not
> suppress exception, code become simplier. We need to catch exceptions only in
> Get_Line routines. Exceptions in Open routine do not need to be catched
> becouse we do not need to close not opened file. For the Ada semantic File we
> can write just.

I hereby promise I won't ignore the I/O exceptions in real code (or at 
least I'll try not to :-)), that example was just an example.

> exception
>     when Device_Error | Data_Error =>
>           --  Device_Error and Data_Error could be raised only on IO
> operations
>           --  So the file is already opened and we do not need to check is
> file open
>           --  before close.

But Open and Close may raise Device_Error too?

>           Close_File (File);

Again, you have to remember to close the file in two places.

>           raise;
> end Read_Something;

Sergey.

Re: I/O - exception handling

[Larry Kilgallen]

In article <HcAAa.13109$xV3.2235@nwrdny03.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> The main problem is that when you get an error on closing a
> file, there's no recovery possible short of trying to recreate
> its contents somehow and somewhere. It's more like a hardware
> error than anything else.

And hardware errors are also well worth reporting to the humans.

Re: I/O - exception handling

[Lutz Donnerhacke]

* Preben Randhol wrote:
>    procedure One_Of_Your_Procedures_That_Open_Files 
>    is
>    begin
>       Open (File, Name => "test.txt", Mode => In_File);
>       Get_Line (File, S1);
>       Get_Line (File, S2);
> 
>       Safe_Close (File);
>    exception
>       when others =>
>          Safe_Close (File);
>    end Read_Something;
> 
> Now you can use the Safe_Close in any function you like.

Why not:

    procedure Read_Something is
       File : File_Type;
    begin
       Open (File, Name => "test.txt", Mode => In_File);
       
       declare
          S1, S2 : String (1 .. 90);
       begin
          Get_Line (File, S1);
          Get_Line (File, S2);
       exception
          when others => Print_Line("ERROR!");
       end;
       
       Close (File);
    exception
       when others => Print_Line("ERROR!");
    end Read_Something;

Close will not be called if Open failed.

Re: I/O - exception handling

[Preben Randhol]

Sergey Koshcheyev wrote:
> 
>>  begin
>>     Open (File, Name => "test.txt", Mode => In_File);
>>     Get_Line (File, S1);
>>     Get_Line (File, S2);
>>     Close_File;
>> 
>>  exception
>>     when others =>
>>          Close_File;
>> end Read_Something;
> 
> This closes the file twice, as does the example below - something I 
> don't like.

No it doesn't. Well that is since you do the when others => and if you
get an error in Close_File (why doesn't it take arguments btw?) then it
will call Close_File again. But if you get an exception in Open the
program will jump to the exception bit and not go through the other
steps.


-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Preben Randhol]

Robert I. Eachus wrote:
> Preben Randhol wrote:
>> 
>> OK understand. *I* would then do:
>> 
>>    procedure Safe_Close (File : File_Type)...
>> 
>> Now you can use the Safe_Close in any function you like.
> 
> I have "decorated" open and close routines that I keep copying around 
> and using in even simple utilities because even the most minimal code to 
>   open a file, check that the open succeeded, or print a diagnotic if it 
> didn't runs to over a page.  But I haven't considered these things as a 
> good candidate for standardization because there are just too many 
> different text strings--and personal preferences--involved.
> 
> The other problem is that the open routine can't exit from the enclosing 
> procedure, so after printing a diagnostic, it has to reraise the 
> exception (or raise some other exception).  This is fine if the program 
> can't run without an input file, but there are other cases where you 
> might want to continue.  Gets complicated, but that is the nature of a 
> file that may or may not exist, and may not be accessable due to 
> permissions, or may be open by some other program for writing and so on.
> 
> The only conclusion I have reached is that there is no such thing as 
> "simply" opening a file.

I agree with that. I also have made a function called: Get_Whole_Line
which I use sometimes. What it does it that if a line is longer than the
buffer you try to read it into it skips the rest of the line.

hello mister
handshake
godbye

If I only want to read the first 5 characters of each line I simply use
my Get_Whole_Line procedure with a String (1 .. 5), but I don't think it
should be standardized as it is more a special case. Though handy
sometimes.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Preben Randhol]

Lutz Donnerhacke wrote:

> IMHO the most Ada Style solution is:

> procedure t is
>    filename : aliased String := "test.txt";

Just curious, why do you make it an aliased String?

> package Auto_File is
>    type Auto_Close_File (name : access String) is limited private;
>    function To_File (a : Auto_Close_File) return File_Type;
> private

[...]

>    type Auto_Close_File (name : access String) is
>      new Ada.Finalization.Limited_Controlled with record
>       file : File_Type;
>       open : Boolean := False;
>    end record;

[...]

>    procedure Initialize(a : in out Auto_Close_File) is
>    begin
>       Open(a.file, In_File, a.name.all);

This a.name where does this come from?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Lutz Donnerhacke]

* Preben Randhol wrote:
> Lutz Donnerhacke wrote:
>> IMHO the most Ada Style solution is:
> 
>> procedure t is
>>    filename : aliased String := "test.txt";
> 
> Just curious, why do you make it an aliased String?

Because I need an access from.

>>    type Auto_Close_File (name : access String) is
>>      new Ada.Finalization.Limited_Controlled with record
>>       file : File_Type;
>>       open : Boolean := False;
>>    end record;
> 
> [...]
> 
>>    procedure Initialize(a : in out Auto_Close_File) is
>>    begin
>>       Open(a.file, In_File, a.name.all);
> 
> This a.name where does this come from?

From the type Auto_Close_File. The constraint is named.

Re: I/O - exception handling

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> The main problem is that when you get an error on closing a
> file, there's no recovery possible short of trying to recreate
> its contents somehow and somewhere. It's more like a hardware
> error than anything else.

But it is _still_ necessary to pay attention to this case. Using
fclose() in C (which GNAT calls upon), is a good example. If the
underlying fclose() fails this could represent a variety of serious
program flaws and/or media defects:

  - If there has been no prior Flush (or fflush in C), then this
    could be a "write error" for buffered data - this could have
    serious consequences.

  - If you have closed the underlying file descriptor that the
    File_Type (or FILE in C) is using, then unwritten data is
    also not getting out (In Ada this can be done by using
    POSIX.IO.Close(File_Descriptor) somewhere else in the code).

Basically, if close fails, this indicates that you most likely
have a serious code flaw, or at minimum, that you have a hardware
media problem (or possibly some other corruption problem).

IMO, the worst thing you can do is ignore the problem, unless
for example you are _expecting_ failures.

Maybe this is stating the obvious, but an example of this
might be where you might do this in C, where you want to be
sure that any files that were opened by the parent process, are
now closed:

   if ( !(PID = fork()) ) {
        /* In child process */
        for ( fd = 0; x < NOFILE; ++x )
              close(fd);   /* Ignore errors: close all files */

I think raising exceptions in close makes sense, because I have
not found too many programs that actually check that close succeeds.
Those same programs do not call fflush prior to the close either
(if they do, they don't check the result).  If this were an editor
for example, I would be extremely annoyed that the last 4K of my
code got truncated because the close()->fflush() call failed because
the file system returned ENOSPC!  I would expect that the editor
would then either keep my original source file somewhere else or
that I get another chance to save it, somewhere else.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: I/O - exception handling

[Dmitriy Anisimkov]

Sergey Koshcheyev wrote:
> I hereby promise I won't ignore the I/O exceptions in real code (or at 
> least I'll try not to :-)), that example was just an example.

Ok, If so you do not need to suppress exception, let it go further if it is occured in Close.
 
> Again, you have to remember to close the file in two places.

Yes, I miss a bit "final" Borland Delphi reserver word too, but I think it is not big deal. You could have a local procedure for the finalization of Local allocated resources, and call it twice, from end of procedure and in the exception handler. Maybe Ada200X would have a something like "final" in Borland Delphi. Is there somebody who think that the syntax like

declare
   Resource : Resource_Type;
begin
   Open (Resource);
   Use_This (Resource);
exception
   when Constraint_Error => Do_Something;
final
   if Is_Open (Resource) then
     Close (Resource);
   end if;
end;

Is bad or not safe ?

Where block from "final" to "end" would be executed in both cases, normal and any-exceptional.

Re: I/O - exception handling

[Ludovic Brenta]

Dmitriy Anisimkov <anisimkov@yahoo.com> writes:

> declare
>    Resource : Resource_Type;
> begin
>    Open (Resource);
>    Use_This (Resource);
> exception
>    when Constraint_Error => Do_Something;
> final
>    if Is_Open (Resource) then
>      Close (Resource);
>    end if;
> end;
> 
> Is bad or not safe ?
> 
> Where block from "final" to "end" would be executed in both cases,
> normal and any-exceptional.


How different is this from:

declare
   Resource : Resource_Type;
begin
   begin
      Open (Resource);
      Use_This (Resource);
   exception
      when Constraint_Error =Do_Something;
   end;
   if Is_Open (Resource) then
     Close (Resource);
   end if;
end;

I think that this is the C++ idiom, too.

-- 
Ludovic Brenta.

Re: I/O - exception handling

[Sergey Koshcheyev]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbd6r2b.31i.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Sergey Koshcheyev wrote:
> > This closes the file twice, as does the example below - something I
> > don't like.
>
> No it doesn't. Well that is since you do the when others => and if you
> get an error in Close_File (why doesn't it take arguments btw?) then it
> will call Close_File again. But if you get an exception in Open the
> program will jump to the exception bit and not go through the other
> steps.

Sorry, I didn't mean "closes the file twice", but "closes the file in two
places".

Sergey.

Re: I/O - exception handling

[Sergey Koshcheyev]

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrnbd6m69.vh.lutz@taranis.iks-jena.de...
> * Sergey Koshcheyev wrote:
> > I have this problem: I have a simple piece of code opening a file,
> > reading a few lines, then closing it. Now, I want this piece of code to
> > be "safe", i.e. not to leak any resources (the open file) in case of
> > errors and not to propagate any exceptions. What is the best style to
> > write this code?
>
> IMHO the most Ada Style solution is:

<skipped>

Oh, well, but this is soo verbose... feels like using a cannon on flies.

Sergey.

Re: I/O - exception handling

[Larry Kilgallen]

In article <bb0ct2$1740$1@ns.felk.cvut.cz>, "Sergey Koshcheyev" <serko84@hotmail.com> writes:

> Oh, well, but this is soo verbose... feels like using a cannon on flies.

By "this" did you mean comp.lang.ada ?  :-)

Re: I/O - exception handling

[Hyman Rosen]

Warren W. Gay VE3WWG wrote:
 > If the underlying fclose() fails this could represent
 > a variety of serious program flaws and/or media defects:

It could represent Martians shooting rayguns at your disk,
too. My point is that there's absolutely nothing you can
do about it except perhaps trying to recreate the entire
file.

> I think raising exceptions in close makes sense

The problem is that if you're doing close in finalization,
allowing an exception to escape leads to program termination
in C++ and raising Program_Error in Ada. That's why you have
dual-mode closing, with an explicit close request that you
can check for error, and an automatic close in finalization
where you ignore the error.

Re: I/O - exception handling

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Warren W. Gay VE3WWG wrote:
>  > If the underlying fclose() fails this could represent
>  > a variety of serious program flaws and/or media defects:
> 
> It could represent Martians shooting rayguns at your disk,
> too. My point is that there's absolutely nothing you can
> do about it except perhaps trying to recreate the entire
> file.

Except for the point made below, my point only was to
note that the problem "occurred", but see below..

>> I think raising exceptions in close makes sense
> 
> The problem is that if you're doing close in finalization,
> allowing an exception to escape leads to program termination
> in C++ and raising Program_Error in Ada. That's why you have
> dual-mode closing, with an explicit close request that you
> can check for error, and an automatic close in finalization
> where you ignore the error.

Yes, OK. Your point is about this happening in finalization
(or destructor). Yes, this is a thorny problem indeed, and when
this happens, "Mars has attacked!" ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: I/O - exception handling

[Hyman Rosen]

Larry Kilgallen wrote:
> And hardware errors are also well worth reporting to the humans.

Sure. The main issue is the problem of throwing exceptions
from destructors or Finalize. Neither C++ nor Ada likes it
when you do that, so that blocks off the usual channel for
such reporting.

Re: I/O - exception handling

[Jeffrey Carter]

I'm not sure what all the fuss is about. Close can only raise 
Status_Error, and only if the file is not open (ARM A.8.2). Is_Open may 
not raise an exception (ARM A.8.2). So the pattern

begin
    Open (File, ...);

    -- Process File

    Close (File);
    -- If Open failed, we do not get here, so this cannot
    -- raise an exception
exception
when others =>
    if Is_Open (File) then
       Close (File);
    end if;
end;

is completely safe.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers

Re: I/O - exception handling

[Sergey Koshcheyev]

Jeffrey Carter wrote:
> I'm not sure what all the fuss is about. Close can only raise 
> Status_Error, and only if the file is not open (ARM A.8.2).

Is it really so? The ARM says (regarding Close):

"The exception Status_Error is propagated if the given file is not open."

I'm not a language lawyer, but I don't think this sentence forbids any 
other behavior (like Device_Errors or Use_Errors).

 > Is_Open may not raise an exception (ARM A.8.2).

ARM A.8.2 (29) also says:

"An implementation may propagate Name_Error or Use_Error if an attempt 
is made to use an I/O feature that cannot be supported by the 
implementation due to limitations in the external environment. Any such 
restriction should be documented."

Since Is_Open is an I/O feature, this means to me that it may raise one 
of these exceptions too.

Or am I being way too "legal"?

> So the pattern
> 
> begin
>    Open (File, ...);
> 
>    -- Process File
> 
>    Close (File);
>    -- If Open failed, we do not get here, so this cannot
>    -- raise an exception
> exception
> when others =>
>    if Is_Open (File) then
>       Close (File);
>    end if;
> end;
> 
> is completely safe.

This has "Close (File)" in two places, so it is also against the "do 
everything only once" principle.

Maybe my requirements are too hard and unrealistic, but anyway, I have 
already found an almost perfect solution, described in one of my earlier 
posts (where I ignore errors from Close).

Sergey.

Re: I/O - exception handling

[Preben Randhol]

Sergey Koshcheyev wrote:
> Since Is_Open is an I/O feature, this means to me that it may raise one 
> of these exceptions too.

The implementation of Is_Open in Gnat (3.14p) is:

   -------------
   -- Is_Open --
   -------------

   function Is_Open (File : in AFCB_Ptr) return Boolean is
   begin
      return (File /= null);
   end Is_Open;

So I don't see that this can raise an exception.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Randy Brukardt]

Preben Randhol wrote in message ...
>Sergey Koshcheyev wrote:
>> Since Is_Open is an I/O feature, this means to me that it may raise
one
>> of these exceptions too.
>
>The implementation of Is_Open in Gnat (3.14p) is:
...
>So I don't see that this can raise an exception.


But of course Gnat /= Ada.

While I don't think any implementor would plan to raise an exception
from Is_Open, certainly the standard allows Use_Error or Device_Error
and of course Storage_Error and Program_Error (if there are elaboration
problems). In practice, I think it's safe to ignore that possibility.

            Randy.

Re: I/O - exception handling

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Sergey Koshcheyev wrote:
> > I myself miss constructors and destructors in Ada a lot.
> 
> Well, Ada has them, albeit in an inconvenient form. You need a
> type which inherits from Controlled, and that type must be
> declared at library level for some safety reason that Ada folks
> appreciate.
> 
> I don't know if there's a way to use access discriminants in
> combination with generics to get a "universal" cleanup object
> that could forward to a function. Ada experts?

The problem is that finalization code has to be at library level, so it
can't easily get its hands on local objects.  A solution/workaround is
to declare a Limited_Controlled type with an access discriminant, and
make that discrim point at the local object.  It's kind of ugly, but
it's exception-safe and abort-safe.  You have to make the local object
aliased.  And if the "local object" is a parameter (which it often is,
in my experience), then you have to make the type tagged so it will be
aliased, or you have to copy the param into a local aliased object.  And
you have to use 'Unchecked_Access, even though there is little danger of
creating dangling pointers.

I suppose you could wrap this "design pattern" in a generic, but I doubt
if it would be pretty.  Note that a generic instantiation must be at
library level if it contains a controlled type.

- Bob

Re: I/O - exception handling

[Robert I. Eachus]

Randy Brukardt wrote:

> While I don't think any implementor would plan to raise an exception
> from Is_Open, certainly the standard allows Use_Error or Device_Error
> and of course Storage_Error and Program_Error (if there are elaboration
> problems). In practice, I think it's safe to ignore that possibility.

Totally agree with respect to Is_Open. However, there are cases where 
exceptions on Close are not only possible but likely in some situations. 
  For example it is perfectly legal in Ada to close Standard_Output and 
other standard files.  There was even an AI a while back making it clear 
that it is legal to do so, and what it means if the implementation does 
support it.  But implementations (notice, not compilers, this is a 
target OS or environment issue) may not allow some files to be closed, 
and you will get Use_Error.

Re: I/O - exception handling

[Jeffrey Carter]

Robert I. Eachus wrote:
> Randy Brukardt wrote:
> 
>> While I don't think any implementor would plan to raise an exception
>> from Is_Open, certainly the standard allows Use_Error or Device_Error
>> and of course Storage_Error and Program_Error (if there are elaboration
>> problems). In practice, I think it's safe to ignore that possibility.
> 
> Totally agree with respect to Is_Open. However, there are cases where 
> exceptions on Close are not only possible but likely in some situations. 
>  For example it is perfectly legal in Ada to close Standard_Output and 
> other standard files.  There was even an AI a while back making it clear 
> that it is legal to do so, and what it means if the implementation does 
> support it.  But implementations (notice, not compilers, this is a 
> target OS or environment issue) may not allow some files to be closed, 
> and you will get Use_Error.

The language lawyers have spoken. To summarize, if I understand 
correctly, if you're dealing with "normal" files (not a standard file or 
device), Is_Open won't raise an exception and Close will only raise an 
exception if the file isn't open.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail

Re: I/O - exception handling

[Manuel Collado]

Jeffrey Carter wrote:
> Robert I. Eachus wrote:
> ...
> The language lawyers have spoken. To summarize, if I understand 
> correctly, if you're dealing with "normal" files (not a standard file or 
> device), Is_Open won't raise an exception and Close will only raise an 
> exception if the file isn't open.

What about internally buffered Write operations? If they are deferred, 
exceptions valid for Write could also be raised at Flush or Close time, 
right?

-- 
To reply by e-mail, please remove the extra dot
in the given address:  m.collado -> mcollado

Re: I/O - exception handling

[Preben Randhol]

Randy Brukardt wrote:
> Preben Randhol wrote in message ...
>>Sergey Koshcheyev wrote:
>>> Since Is_Open is an I/O feature, this means to me that it may raise
> one
>>> of these exceptions too.
>>
>>The implementation of Is_Open in Gnat (3.14p) is:
> ...
>>So I don't see that this can raise an exception.
> 
> 
> But of course Gnat /= Ada.
> 
> While I don't think any implementor would plan to raise an exception
> from Is_Open, certainly the standard allows Use_Error or Device_Error
> and of course Storage_Error and Program_Error (if there are elaboration
> problems). In practice, I think it's safe to ignore that possibility.

I see, but why would it? I mean why would Is_Open start poking in the
I/O. On Linux/Unix you don't lock files as in Windows, so you cannot
tell if the file is opened or not as 10 programs may open it at the same
time. Therefore I thought the implementation would be a test if the Open
procedure succeded or not?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Larry Kilgallen]

In article <slrnbde04e.ps.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:

> I see, but why would it? I mean why would Is_Open start poking in the
> I/O. On Linux/Unix you don't lock files as in Windows, so you cannot
> tell if the file is opened or not as 10 programs may open it at the same
> time. Therefore I thought the implementation would be a test if the Open
> procedure succeded or not?

Certainly.

    1. function Is_Open(File : in File_Type) return Boolean;

         1. Returns True if the file is open (that is, if it is associated
	    with an external file), otherwise returns False. 

That does not seem to have anything to do with whether other programs
have associated with the same external file.

Re: I/O - exception handling

[Preben Randhol]

Larry Kilgallen wrote:
> In article <slrnbde04e.ps.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> 
>> I see, but why would it? I mean why would Is_Open start poking in the
>> I/O. On Linux/Unix you don't lock files as in Windows, so you cannot
>> tell if the file is opened or not as 10 programs may open it at the same
>> time. Therefore I thought the implementation would be a test if the Open
>> procedure succeded or not?
> 
> Certainly.
> 
>     1. function Is_Open(File : in File_Type) return Boolean;
> 
>          1. Returns True if the file is open (that is, if it is associated
> 	    with an external file), otherwise returns False. 
> 
> That does not seem to have anything to do with whether other programs
> have associated with the same external file.

No, so then why would an exception in Is_Open be expected at all? Are
there some perculiar hardware where you need to poke into the I/O to see
if a file was opened?

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Larry Kilgallen]

In article <slrnbdef7h.79e.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> Larry Kilgallen wrote:
>> In article <slrnbde04e.ps.randhol+abuse@kiuk0152.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
>> 
>>> I see, but why would it? I mean why would Is_Open start poking in the
>>> I/O. On Linux/Unix you don't lock files as in Windows, so you cannot
>>> tell if the file is opened or not as 10 programs may open it at the same
>>> time. Therefore I thought the implementation would be a test if the Open
>>> procedure succeded or not?
>> 
>> Certainly.
>> 
>>     1. function Is_Open(File : in File_Type) return Boolean;
>> 
>>          1. Returns True if the file is open (that is, if it is associated
>> 	    with an external file), otherwise returns False. 
>> 
>> That does not seem to have anything to do with whether other programs
>> have associated with the same external file.
> 
> No, so then why would an exception in Is_Open be expected at all? Are
> there some perculiar hardware where you need to poke into the I/O to see
> if a file was opened?

???

By "Certainly" I meant agreement.

I was not one who said an exception in Is_Open would be expected.

Re: I/O - exception handling

[Preben Randhol]

Larry Kilgallen wrote:
> 
> By "Certainly" I meant agreement.

Ah sorry. I got confused by the last paragraph you wrote.

-- 
Preben Randhol                    http://www.pvv.org/~randhol/

Re: I/O - exception handling

[Randy Brukardt]

Preben Randhol wrote in message ...
>No, so then why would an exception in Is_Open be expected at all? Are
>there some perculiar hardware where you need to poke into the I/O to
see
>if a file was opened?


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

          Randy.

Re: I/O - exception handling

[Robert I. Eachus]

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.

Re: I/O - exception handling

[Randy Brukardt]

Robert I. Eachus wrote in message <3EDA24D2.6060003@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.


Of course, but the question I was answering was about Is_Open, not
Close. I would give different advice about Close, for the reasons you
give. But a compiler raising Use_Error on Is_Open would be pretty weird
(and unhelpful).

                Randy.

Re: I/O - exception handling

[Robert I. Eachus]

Randy Brukardt wrote:

> Of course, but the question I was answering was about Is_Open, not
> Close. I would give different advice about Close, for the reasons you
> give. But a compiler raising Use_Error on Is_Open would be pretty weird
> (and unhelpful).

If I seemed to be disagreeing with you, the fault is mine.  I certainly 
don't want to imagine a file type where Use_Error on Is_Open makes 
sense, let alone actually use such a file!  Hmmm.  That file state is 
being maintained on Triton, but this is a real time system, and I 
guarantee a response within 100 microseconds--okay Use_Error it is...