mirror of
https://github.com/codeguy/php-the-right-way.git
synced 2025-08-14 01:33:58 +02:00
Merge pull request #363 from astorm/gh-pages
Rewrite to remove inaccurate @ logging text.
This commit is contained in:
@@ -59,39 +59,33 @@ You can also control whether or not errors are displayed to the screen (good for
|
|||||||
|
|
||||||
### Inline Error Suppression
|
### Inline Error Suppression
|
||||||
|
|
||||||
You can also suppress specific errors from being displayed using the Error Control Operator `@`. You simply put
|
You can also tell PHP to suppress specific errors with the Error Control Operator `@`. You put
|
||||||
this operator at the beginning an expression, and any error that would be caused as a direct result of the specific
|
this operator at the beginning of an expression, and any error that's a direct result of the expression is silenced.
|
||||||
expression will be silenced.
|
|
||||||
|
|
||||||
{% highlight php %}
|
{% highlight php %}
|
||||||
echo @$foo['bar'];
|
echo @$foo['bar'];
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
This will output `$foo['bar']` if it exists, but will simply return a null and print nothing if the variable `$foo` or
|
This will output `$foo['bar']` if it exists, but will simply return a null and print nothing if the variable `$foo` or
|
||||||
`'bar'` key does not exist.
|
`'bar'` key does not exist. Without the error control operator, this expression could create a `PHP Notice: Undefined variable: foo` or `PHP Notice: Undefined index: bar` error.
|
||||||
|
|
||||||
This might seem like a good idea, but due to the way PHP actually handles `@` it is incredibly unperformant, and has the
|
This might seem like a good idea, but there are a few undesirable tradeoffs. PHP handles expressions using an `@` in a less performant way than expressions without an `@`. Premature optimization may be the root of all programming arguments, but if performance is particularly important for your application/library it's important to understand the error control operator's performance implications.
|
||||||
unexpected effect of still actually logging the error anyway. If you have this code in a loop that runs 100 times in an
|
|
||||||
instance, and you run that 1 million times, then you've got 100 million lines in your logs.
|
|
||||||
|
|
||||||
Instead, use the following:
|
Secondly, the error control operator **completely** swallows the error. The error is not displayed, and the error is not send to the error log. Also, stock/production PHP systems have no way to turn off the error control operator. While you may be correct that the error you're seeing is harmless, a different, less harmless error will be just as silent.
|
||||||
|
|
||||||
|
If there's a way to avoid the error suppression operator, you should consider it. For example, our code above could be rewritten like this
|
||||||
|
|
||||||
{% highlight php %}
|
{% highlight php %}
|
||||||
echo isset($foo['bar']) ? $foo['bar'] : '';
|
echo isset($foo['bar']) ? $foo['bar'] : '';
|
||||||
{% endhighlight %}
|
{% endhighlight %}
|
||||||
|
|
||||||
This will be much quicker, and save filling up your logs with junk. [SitePoint] go a step further and say you should
|
|
||||||
[never suppress notices] with `@`.
|
|
||||||
|
|
||||||
One instance where error suppression might make sense is where `fopen()` fails to find a file to load. You could check
|
One instance where error suppression might make sense is where `fopen()` fails to find a file to load. You could check
|
||||||
for existence of the file before you try to load it, but if the file is deleted after the check and before the `fopen()`
|
for the existence of the file before you try to load it, but if the file is deleted after the check and before the `fopen()`
|
||||||
(which might sound impossible, but it can happen) then `fopen()` will return false _and_ throw an error. This is
|
(which might sound impossible, but it can happen) then `fopen()` will return false _and_ throw an error. This is
|
||||||
potentially something PHP should resolve, but is one case where error suppression might seem like the only valid
|
potentially something PHP should resolve, but is one case where error suppression might seem like the only valid
|
||||||
solution.
|
solution.
|
||||||
|
|
||||||
In a stock PHP system, the behavior of the error control operator is irreversible. There are no configuration settings which allow a suppressed error to be temporarily un-suppressed.
|
Earlier we mentioned there's no way in a stock PHP system to turn off the error control operator. However, [xDebug] has an `xdebug.scream` ini setting which will disable the error control operator. You can set this via your `php.ini` file with the following.
|
||||||
|
|
||||||
However, [xDebug] has an `xdebug.scream` ini setting which will disable the error control operator. You can set this via your `php.ini` file with the following.
|
|
||||||
|
|
||||||
xdebug.scream = On
|
xdebug.scream = On
|
||||||
|
|
||||||
@@ -108,7 +102,6 @@ This is most useful when you're debugging code and suspect an informative error
|
|||||||
|
|
||||||
* [Error Control Operators](http://php.net/manual/en/language.operators.errorcontrol.php)
|
* [Error Control Operators](http://php.net/manual/en/language.operators.errorcontrol.php)
|
||||||
* [SitePoint](http://www.sitepoint.com/)
|
* [SitePoint](http://www.sitepoint.com/)
|
||||||
* [never suppress notices](http://www.sitepoint.com/why-suppressing-notices-is-wrong/)
|
|
||||||
* [xDebug](http://xdebug.org/docs/basic)
|
* [xDebug](http://xdebug.org/docs/basic)
|
||||||
* [Scream](http://www.php.net/manual/en/book.scream.php)
|
* [Scream](http://www.php.net/manual/en/book.scream.php)
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user