Please, read this for reference:
http://drupal.org/node/16309

I guess when a coder has choosen to ignore PHP warnings using the @ operator, so as to not confuse users with them, it makes no sense to see such messages in the drupal logs.

Please, consider to add this to 4.7. It is particulary annoying when using certain functions such as fsockopen that tend to generate lots of these thingies.

TIA

CommentFileSizeAuthor
#1 common.inc.patch-a846 bytesmarkus_petrux

Comments

markus_petrux’s picture

Status: Active » Needs review
StatusFileSize
new846 bytes

Please, consider applying this patch. It makes no sense to log PHP notices when the programmer has decided to avoid them by using the @ operator. This is specially important when using functions such as fsockopen because warnings are always generated. The only option for the programmer is the @ operator.

Otherwise, drupal administrators will get confused by records in their logs the mean nothing.

Patch attached.

markus_petrux’s picture

Version: 4.7.0-beta1 » x.y.z
markus_petrux’s picture

Status: Needs review » Reviewed & tested by the community

???

markus_petrux’s picture

Status: Reviewed & tested by the community » Needs work

hmm... actually, the site administrator is allowed to choose what to do with PHP errors (error_level option in admin/settings).

What about adding another option to let them choose what to do with PHP warnings removed by the @ operator?

The error_handler could look like this:

function error_handler($errno, $message, $filename, $line) {
  if (IGNORE_AT_SIGN_REMOVED_WARNINGS && error_reporting() == 0) {
    return;
  }

  ...
  ...
  ...

Where IGNORE_AT_SIGN_REMOVED_WARNINGS could be a constant defined as soon as the bootstrap process allows to use the variable_get() function.

Jaza’s picture

Version: x.y.z » 6.x-dev

Moving to 6.x-dev. Is this still needed? Was it ever?

Crell’s picture

Status: Needs work » Closed (won't fix)

The @ sign to hide errors is a hack, and has no purpose except as a hack. There's a strong push to make Drupal E_ALL compliant, in which case anything that the @ sign would hide SHOULD be shown, loudly, so that it can be fixed.

The only time @ is even appropriate in the first place is on badly-written functions like ldap_bind() that throw a warning on normal "not found" operations. Otherwise, it leads to bad code, and Drupal doesn't need bad code.