Closed (won't fix)
Project:
Drupal core
Version:
6.x-dev
Component:
base system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
15 Dec 2005 at 00:19 UTC
Updated:
18 Jan 2007 at 06:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
markus_petrux commentedPlease, 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.
Comment #2
markus_petrux commentedComment #3
markus_petrux commented???
Comment #4
markus_petrux commentedhmm... 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:
Where IGNORE_AT_SIGN_REMOVED_WARNINGS could be a constant defined as soon as the bootstrap process allows to use the variable_get() function.
Comment #5
Jaza commentedMoving to 6.x-dev. Is this still needed? Was it ever?
Comment #6
Crell commentedThe @ 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.