This blog post is all about how to handle errors from the PHP file_get_contents function, and others which work like it.
The file_get_contents function will read the contents of a file into a string. For example:
<?php
$text = file_get_contents("hello.txt");
echo $text;
You can try this out on the command-line like so:
$ echo "hello" > hello.txt
$ php test.php
hello
This function is widely used, but I’ve observed that error handling around it is often not quite right. I’ve fixed a few bugs involving incorrect I/O error handling recently, so here are my thoughts on how it should be done.
How file_get_contents fails
For legacy reasons, this function does not throw an exception when something goes wrong. Instead, it will both log a warning, and return false.
<?php
$filename = "not-a-real-file.txt";
$text = file_get_contents($filename);
echo $text;
Which looks like this when you run it:
$ php test.php
PHP Warning: file_get_contents(not-a-real-file.txt): failed to open stream: No such file or directory in test.php on line 3
PHP Stack trace:
PHP 1. {main}() test.php:0
PHP 2. file_get_contents() test.php:3
Warnings are not very useful on their own, because the code will continue on without the correct data.
Error handling in four steps
If anything goes wrong when you are reading a file, your code should be throwing some type of Exception which describes the problem. This allows developers to put a try {} catch {} around it, and avoids nasty surprises where invalid data is used later.
Step 1: Detect that the file was not read
Any call to file_get_contents should be immediately followed by a check for that false return value. This is how you know that there is a problem.
<?php
$filename = "not-a-real-file.txt";
$text = file_get_contents($filename);
if($text === false) {
throw new Exception("File was not loaded");
}
echo $text;
This now gives both a warning and an uncaught exception:
$ php test.php
PHP Warning: file_get_contents(not-a-real-file.txt): failed to open stream: No such file or directory in test.php on line 3
PHP Stack trace:
PHP 1. {main}() test.php:0
PHP 2. file_get_contents() test.php:3
PHP Fatal error: Uncaught Exception: File was not loaded in test.php:5
Stack trace:
#0 {main}
thrown in test.php on line 5
Step 2: Suppress the warning
Warnings are usually harmless, but there are several good reasons to suppress them:
- It ensures that you are not depending on a global error handler (or the absence of one) for correct behaviour.
- The warning might appear in the middle of the output, depending on
php.ini. - Warnings can produce a lot of noise in the logs
Use @ to silence any warnings from a function call.
<?php
$filename = "not-a-real-file.txt";
$text = @file_get_contents($filename);
if($text === false) {
throw new Exception("File was not loaded");
}
echo $text;
The output is now only the uncaught Exception:
$ php test.php
PHP Fatal error: Uncaught Exception: File was not loaded in test.php:5
Stack trace:
#0 {main}
thrown in test.php on line 5
Step 3: Get the reason for the failure
Unfortunately, we lost the “No such file or directory” message, which is pretty important information, which should go in the Exception. This information is retrieved from the old-style error_get_last method.
This function might just return empty data, so you should check that everything is set and non-empty before you try to use it.
<?php
$filename = "not-a-real-file.txt";
error_clear_last();
$text = @file_get_contents($filename);
if($text === false) {
$e = error_get_last();
$error = (isset($e) && isset($e['message']) && $e['message'] != "") ?
$e['message'] : "Check that the file exists and can be read.";
throw new Exception("File '$filename' was not loaded. $error");
}
echo $text;
This now embeds the failure reason directly in the message.
$ php test.php
PHP Fatal error: Uncaught Exception: File 'not-a-real-file.txt' was not loaded. file_get_contents(not-a-real-file.txt): failed to open stream: No such file or directory in test.php:9
Stack trace:
#0 {main}
thrown in test.php on line 9
Step 4: Add a fallback
The last time I introduced error_clear_last()/get_last_error() into a code-base, I learned out that HHVM does not have these functions.
Call to undefined function error_clear_last()
The fix for this is to write some wrapper code, to verify that each function exists.
<?php
$filename = 'not-a-real-file';
clearLastError();
$text = @file_get_contents($filename);
if ($text === false) {
$error = getLastErrorOrDefault("Check that the file exists and can be read.");
throw new \Exception("Could not retrieve image data from '$filename'. $error");
}
echo $text;
/**
* Call error_clear_last() if it exists. This is dependent on which PHP runtime is used.
*/
function clearLastError()
{
if (function_exists('error_clear_last')) {
error_clear_last();
}
}
/**
* Retrieve the message from error_get_last() if possible. This is very useful for debugging, but it will not
* always exist or return anything useful.
*/
function getLastErrorOrDefault(string $default)
{
if (function_exists('error_clear_last')) {
$e = error_get_last();
if (isset($e) && isset($e['message']) && $e['message'] != "") {
return $e['message'];
}
}
return $default;
}
This does the same thing as before, but without breaking other PHP runtimes.
$ php test.php
PHP Fatal error: Uncaught Exception: Could not retrieve image data from 'not-a-real-file'. file_get_contents(not-a-real-file): failed to open stream: No such file or directory in test.php:7
Stack trace:
#0 {main}
thrown in test.php on line 7
Since HHVM is dropping support for PHP, I expect that this last step will soon become unnecessary.
How not to handle errors
Some applications put a series of checks before each I/O operation, and then simply perform the operation with no error checking. An example of this would be:
<?php
$filename = "not-a-real-file.txt";
// Check everything!
if(!file_exists($filename)) {
throw new Exception("$filename does not exist");
}
if(!is_file($filename)) {
throw new Exception("$filename is not a file");
}
if(!is_readable($filename)) {
throw new Exception("$filename cannot be read");
}
// Assume that nothing can possibly go wrong..
$text = @file_get_contents($filename);
echo $text;
You could probably make a reasonable-sounding argument that checks are a good idea, but I consider them to be misguided:
- If you skip any actual error handling, then your code is going to fail in more surprising ways when you encounter an I/O problem that could not be detected.
- If you do perform correct error handling as well, then the extra checks add nothing other than more branches to test.
Lastly, beware of false positives. For example, the above snippet will reject HTTP URL’s, which are perfectly valid for file_get_contents.
Conclusion
Most PHP code now uses try/catch/finally blocks to handle problems, but the ecosystem really values backwards compatibility, so existing functions are rarely changed.
The style of error reporting used in these I/O functions is by now a legacy quirk, and should be wrapped to consistently throw a useful Exception.