ReadFileToString 'raises an exception' - but it doesn't?

[Mario]

Hi,

if I try to open a nonexistent file with ReadFileToString, it seems to simply fail silently. In the docs it says that it raises an exception, a behavior I would welcome. Do I have to turn something on for it to raise the exception? Did I misunderstand something or is there a bug in this?

The docs:

https://lazarus-ccr.sourceforge.io/docs/lazutils/fileutil/readfiletostring.html

Thanks for any hints.

Mario

[AlexTP]

Docs:
>If there is an error while reading the file, an Exception is raised and an empty string is returned.

Docs are correct. During READING the exception is raised.
If file not found - no exception occurs <-- this is omitted in docs.
Docs should be improved.

[Mario]

I see, thanks.

Arguably, if the file does not exist it should raise an exception too. But OK.

[Thaddy]

Usually you test if the file exists, before you try to read it. Always.
The readfiletostring part is never the right place to do that. And should never raise an exception if the file does not exist. That should be done before that and with if/then/else and without any kind of exception handling. That is called programming.

[TRon]

Arguably, if the file does not exist it should raise an exception too. But OK.

Depends on your point of view I guess.

Code: Pascal  [Select][+][-]

1. if FileExists(Filename)
2.  then ReadFileToString(Filename)
3.   else Raise sysutils.EFileNotFoundException.Create(sysconst.SFileNotFound);
4.  

[Thaddy]

ROFL..

[dsiders]

Docs:
>If there is an error while reading the file, an Exception is raised and an empty string is returned.

Docs are correct. During READING the exception is raised.
If file not found - no exception occurs <-- this is omitted in docs.
Docs should be improved.

I've written an update to the topic. It looks like this:

Code: Text  [Select][+][-]

1. ReadFileToString
2.  
3. Returns a string with the contents of the named file.
4.  
5. ReadFileToString opens the file specified in the FileName argument, then
6. reads its contents into the Result string.
7.  
8. FileName can include a path to the file, but cannot include a value which
9. needs to be resolved (like '~' for the home directory on UNIX-like file systems).
10. Relative path notation can be used.
11.  
12. ReadFileToString does not check whether FileName contains a fully-expanded
13. value or whether it exists on the local file system. It does not complain if the
14. file does not exist; the return value is an empty string ('') for these conditions.
15. ExpandFileName() or FileExists() should be called for the file path/ name before
16. ReadFileToString is called.
17.  
18. FileSize is used to determine the size needed for the return value. UNIX-like file
19. systems usually return 0 as the file size if FileName is located on a virtual file system
20. (like /proc). In this case, the return value is an empty string. Another mechanism
21. (like TStringList.LoadfromFile) should be used for virtual files.
22.  
23. FileOpenUTF8 is called to get a shared handle used to read from (but not write to)
24. the specified file name. If an invalid handle is returned, the routine quietly exits with
25. an empty return value.
26.  
27. FileRead is called for the handle to read the number of bytes in the file size into the
28. return value.
29.  
30. FileClose is called to close the handle for the file when the operation has been completed.
31.  
32. Errors
33.  
34. If an error occurs while reading from or closing the file handle, the Exception is handled
35. in the routine and an empty string is returned.
36.  

Feedback appreciated.

[wp]

Line 3: To distinguish from other files I would prefer to see "text file" in this line rather than "file" alone.

Usage of absolute or relative paths is not clear (did not test it myself, though): In line 10 you say "Relative path notation can be used", but in line 10 you require ExpandfileName to be called which would indicate that relative paths are not allowed.

[dsiders]

Line 3: To distinguish from other files I would prefer to see "text file" in this line rather than "file" alone.

Thanks Werner. Changed .

Usage of absolute or relative paths is not clear (did not test it myself, though): In line 10 you say "Relative path notation can be used", but in line 10 you require ExpandfileName to be called which would indicate that relative paths are not allowed.

Relative paths work when valid. Otherwise, it's an empty string.
ExpandFileName was mentioned as a remedy for '~' notation.
I have changed that paragraph to:

Code: Text  [Select][+][-]

1. ReadFileToString does not check whether FileName contains a n expanded value or
2. whether it exists on the local file system. It does not complain if the file
3. does not exist; the return value is an empty string ('') for these conditions.
4. ExpandFileName() can be used to resolve a path with '~' notation. FileExists()
5. or FileExistsUTF8() can be used to verify whether the file path/name exists
6. before ReadFileToString is called.
7.  

Does that help?

[Thaddy]

Why not simply warn that you have to check for existance before you call the function?
I like Tron's unreachable code example to demonstrate that. Or did I miss something...
A beautiful joke for programmers.

But the suggested adaptation by Werner is otherwise perfectly worded.

[wp]

Code: Text  [Select][+][-]

1. ... contains a n expanded value ...

Tiny typo: "a n" --> "an"

[silvercoder70]

Quick random thoughts ...

Not sure of the exact use cases for this function design wise, but ...

if I were to use this function to read a config file, the currently implementation would be OK. If an empty string were returned if no file, then defaults could be easily applied.

if the file were needed, my preference is that a check is done before calling the function.

Code: Pascal  [Select][+][-]

1. if not FileExists(...) then
2. begin
3.   HandleError(...)
4.   Exit;
5. end;
6.  
7. contents := ReadFileToString(...);
8.  

Having to use/rely on exception handling makes things harder for the compiler (.exe) and when bad things happen, making a program inefficient.

[dsiders]

Code: Text  [Select][+][-]

1. ... contains a n expanded value ...

Tiny typo: "a n" --> "an"

I noticed that. Already fixed. Thanks.