Opened 9 months ago
Last modified 7 months ago
#21870 new defect (bug)
@ error control operator hides fatal error on mysql_fetch_object
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Database | Version: | 1.5 |
| Severity: | normal | Keywords: | has-patch 3.6-early |
| Cc: |
Description
I ran a get_posts() query that took me a while to track down to the @ error control operator on the mysql_fetch_object call (see wp-db.php:1219 in trunk), therefore PHP was silently die'ing on me because of a memory limit error.
I'm curious as to what use cases there are for the error control operator to be used here. In my case, I want to see these errors and fix my code accordingly, or tailor my query to the memory constraints, or rethink my data relations in the database.
Attachments (2)
Change History (12)
- Keywords needs-patch added; 2nd-opinion removed
I assume error suppression is used because mysql_fetch_object() throws a notice when there is no object left to fetch.
Should be a way around that, though.
21870.diff avoids error suppression on mysql_fetch_object(), mysql_num_fields(), mysql_fetch_field().
mysql_query() should additionally be good, because $this->dbh is guaranteed to be a resource, I guess unless someone unset it (if the connection fails, we bail in db_connect()). But touching that seems more dangerous than these.
- Keywords has-patch added; needs-patch removed
- Milestone changed from Awaiting Review to 3.5
Not to veer to much in the direction of #9158, but what about the @ operator on the mysql_query call a bit earlier in the function?
$this->result = @mysql_query( $query, $this->dbh );
This seems related and perhaps ripe for removal as well, as any error raised by this call is probably developer error.
Replying to ericlewis:
Not to veer to much in the direction of #9158, but what about the @ operator on the mysql_query call a bit earlier in the function?
$this->result = @mysql_query( $query, $this->dbh );This seems related and perhaps ripe for removal as well, as any error raised by this call is probably developer error.
Since we'll be taking care of support for PDO and the mysqli_* class in #21663, I'm gonna retract what I said about perhaps removing the error construct for mysql_query(), because that could open up a can of worms that really doesn't need to be opened at all.
Thumbs up on nacin's patch.
There are no plans for PDO or mysqli. Not saying it's never going to happen, but *certainly* not for 3.5. Opening the can of worms is fine. I talked about why I avoided mysql_query() above.
Replying to nacin:
Opening the can of worms is fine. I talked about why I avoided mysql_query() above.
Ah whoops, I thought you meant it was good to leave as is.
As per the previous talk, forking open the discussed can of worms and removing the error control operator from mysql_query.
comment:10
nacin — 7 months ago
- Keywords 3.6-early added
- Milestone changed from 3.5 to Future Release

Related: #9158