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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
