[fpc-pascal] Why opening a file for write fails in fpc 2.6?

[Giuliano Colla]

Il 01/11/2012 09:28, Tomas Hajny ha scritto:
> On Thu, November 1, 2012 00:24, Giuliano Colla wrote:
>> Il 31/10/2012 14:45, Jonas Maebe ha scritto:
>>> On 31 Oct 2012, at 14:35, Giuliano Colla wrote:
>   .
>   .
>>>> but if it doesn't it's a Delphi bug, I'd say. What are exceptions
>>>> there for, if not for telling you that what you requested cannot be
>>>> done?
>>> There are multiple ways to indicate a failure. Exceptions are a very
>>> expensive way for doing so, and generally should only be used in cases
>>> that are truly exceptional and/or indicate a fatal error. In other
>>> cases, using a special return value is generally much more appropriate.
>>>
>>>
>> My bad. I hadn't realized that low level file operation such as FileOpen
>> and FileCreate do not raise an exception on failure. I seldom use them,
>> and only in connection with physical devices, where I always take care
>> to verify the existence before attempting to read or write. So I just
>> relied on a useless try-except construct.
>> It's very unlikely that such a failure would permit a program to
>> continue running, I'd call it a fatal error, so an exception would be
>> welcome, but that's life...
> I don't agree with your statement that such an error wouldn't allow the
> program to continue running. Vice versa, there are many situations where
> the result may be used for a different behaviour of the respective
> program. As an example, you may use the return value from FileCreate for
> checking whether the user supplied a valid file name in his input to the
> program (and ask for another file name afterwards), you may also check
> whether you can access the respective file in read/write mode (and thus
> allow user to change the file) or you need to stick to read-only mode (and
> thus allow just viewing/reading the content), etc.
>
You may be right, but the try-except construct is there exactly to 
permit you to handle those situations.
However I'd like to point out a significant inconsistency. Please give a 
look to the following piece of code:

procedure TForm1.Button1Click(Sender: TObject);
var
   MyFile: TextFile;
   AName: String;
begin
   AName:= 'BadName.txt';
   AssignFile(MyFile,AName);
   Reset(MyFile);  <==== Raises an Exception: EInOutError File not found
end;

procedure TForm1.Button2Click(Sender: TObject);
var
   MyFile: Integer;
   AName: String;
begin
   AName:= 'BadName.txt';
   MyFile:= FileOpen(AName,fmOpenRead); <===== Just sets MyFile to -1
end;

Both procedures perform exactly the same action, i.e. they attempt to 
open for reading the non existing file BadName.txt.
The first one gives rise to an exception. The second one doesn't. Your 
considerations should apply to both, or to none. As it is, it's rather 
inconsistent.

Just my 2c

Giuliano