Opened 11 years ago
Last modified 15 months ago
#24780 new defect (bug)
Use error handlers rather than the error suppression operator
Reported by: | rmccue | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Filesystem API | Keywords: | needs-patch |
Focuses: | Cc: |
Description
In various places in core (and included libraries, such as pclzip, FTP and phpass), the error suppression operator is used to suppress warnings and notices. However, this also suppresses fatal errors, which makes it a huge pain for debugging.
The big one here is fopen
, where it is used to suppress warnings when opening a handle fails. For normal files, this is fine since the only errors generated are warnings. When using streams and custom stream handlers, these can generate errors which are really hard to find with this.
(I ran into this with the App Engine plugin, where the SDK method generates a fatal error if the mode is a
, which is used with error suppression in win_is_writable()
.)
Change History (12)
#4
in reply to:
↑ 3
@
11 years ago
Replying to mark-k:
In what way an error handler is better? If I feel that something funny is going on I just look at the error log file. How will having an error handler improve anything?
As Ryan stated, fatal errors are also suppressed when the @ operator is used. This is a complete nightmare when your script dies for no apparent reason. The only option then is to run Xdebug with xdebug.scream set to true. It works, but it's far from ideal.
We should audit core in its entirety and remove as many @ operators as possible. The remaining ones should only be used when WP_DEBUG isn't set to true (example).
I'll be willing to do this at some point. I just lost an hour due to a fatal error that was being suppressed.
#6
follow-up:
↓ 9
@
5 years ago
Doing a quick search on this, there are at least ~200 instances of the @ suppression operator across ~55 files. Maybe to make this process easier we should split it up (by ticket) into smaller bites either by component or file. Most files have less 1 or 2 instances but the class-pclzip.php
file has around 60 instances.
#7
@
5 years ago
Actually, there's around ~400 and I generated a doc to track this if this is something we want to get done. Suppressed Errors Google Doc
This ticket was mentioned in Slack in #core by howdy_mcgee. View the logs.
5 years ago
#9
in reply to:
↑ 6
@
5 years ago
Replying to Howdy_McGee:
Doing a quick search on this, there are at least ~200 instances of the @ suppression operator across ~55 files. Maybe to make this process easier we should split it up (by ticket) into smaller bites either by component or file. Most files have less 1 or 2 instances but the
class-pclzip.php
file has around 60 instances.
Thanks for the research! I think it would make sense to split this into smaller tickets per file or a group of related files.
These files were previously external libraries:
wp-admin/includes/class-ftp-pure.php wp-admin/includes/class-ftp-sockets.php wp-admin/includes/class-ftp.php wp-admin/includes/class-pclzip.php wp-includes/IXR/* wp-includes/class-phpass.php
With the upstream sources seemingly abandoned, they are now treated as "adopted" rather than external, per comment:1:ticket:49163 and comment:2:ticket:48267. That said, I think we should still minimize changes to them and probably exclude them from the first pass. So far, they only received some necessary changes like [32990] / #31982, or minor typo fixes like [47123] / #49163.
These are supported external libraries that should definitely be excluded from any changes here:
wp-includes/ID3/* wp-includes/random_compat/* wp-includes/SimplePie/* wp-includes/class-phpmailer.php wp-includes/class-pop3.php wp-includes/class-requests.php wp-includes/class-smtp.php
In what way an error handler is better? If I feel that something funny is going on I just look at the error log file. How will having an error handler improve anything?
+1 to getting rid of all suppression and trying to actually handle all exceptions (even if by just emitting an error under WP_DEBUG) but I don't think this is the way to get there.