Once upon a time… we had this in our SimpleFilebackend:

return (file_exists($pathAndFilename) ? require_once($pathAndFilename) : FALSE);

Then we figured that using file_exists() is slow, so we changed it to this (see https://review.typo3.org/18873):

return @include_once($pathAndFilename);

That was changed again (in https://review.typo3.org/19848) to:

try {
	return include_once($pathAndFilename);
} catch (\Exception $e) {
	 return FALSE;
}

So much for an introduction.

Currently we have test errors (see TYPO3-Neos-Commit job) because our ClassLoader tries to include a (potentially existing) proxy class using that requireOnce() method of ours. What happens if that class doesn't exist? Usually our exception handling kicks in (notices are transformed to exception), but in case of (recent) PHPUnit, this is not in effect.

So I created https://review.typo3.org/34314 and immediately someone pointed out we had removed the @ in the past. But why?

The problem is, this is misleading. If files are not found, the effect is exactly the same, FALSE is returned, so that the autoloader chain can continue. This is exactly the intended behavior. The actual problem are errors in existing files…

So, assume you include a file with include_once():

1. If the file does exist and all is fine, there is (obviously) no difference
2. If the file does not exist, a notice is emitted and FALSE is returned
3. If the file exists and returns a syntax error, PHP dies with a fatal error

Using the shut-up-operator suppresses the notice in the second case, as expected. The problem is the third case: The @ suppresses the fatal error and you end up without any meaningful information! So that is the reason we had issues with the shut-up-operator.