Clean up the use of @ operator

[chesio]

Inspired by discussion in #98. Here's a list of current uses of @ operator in the plugin:

• inc/cachify.class.php:1596-1598
• inc/class-cachify-apc.php:103
• inc/class-cachify-hdd.php:115
• inc/class-cachify-hdd.php:188
• inc/class-cachify-hdd.php:195
• inc/class-cachify-hdd.php:200
• inc/class-cachify-hdd.php:203
• inc/class-cachify-hdd.php:254
• inc/class-cachify-memcached.php:140

Let's try to reduce this list to necessary minimum :-)

[angcl]

Perhaps this issue could be closed now because #256 was merged.

[stklcode]

The master references in the first comment pointed to inexisting files. I've just updated them by comparing the code from 05/2017 to the current develop state with fixed commit references.

4 usages are left. One of them has custom error handling. Is there any scenario in which a warning from the other calls is really superfluous?

cachify/inc/class-cachify-apc.php

Line 103 in 2abed98

@apc_clear_cache( 'user' );

This is plain suppression without any custom handling. If the call fails, flusing did not work and the user probably won't notice.

cachify/inc/class-cachify-hdd.php

Lines 188 to 189 in 2abed98

	$handle = @fopen( $file, 'wb' );
	if ( ! $handle ) {

Error handling is done in the next line using trigger_error.

cachify/inc/class-cachify-hdd.php

Lines 200 to 201 in 2abed98

	$stat = @stat( dirname( $file ) );
	$perms = $stat['mode'] & 0007777;

If the stat() call fails here and the result is false, a warning is generated in the very next line with a warning like "Trying to access array offset on value of type bool".
I would prefer the original warning "stat failed for [filename]" here.

cachify/inc/class-cachify-hdd.php

Lines 253 to 255 in 2abed98

	if ( self::_user_can_delete( $dir ) && 0 === count( glob( trailingslashit( $dir ) . '*' ) ) ) {
	@rmdir( $dir );
	}

If this fails, we leave some directories on the filesystem. It should not occur, if _user_can_delete is implemented correctly.