No comment on the cause just some observations. Issue exists with SQLite as well. 

PHP 5.3 CVS

MySQL results:

 emulated prepared statements - not using traversable - OK
 emulated prepared statement  -     using traversable - Issue exists
 
 native prepared statements   - not using traversable - OK
 native prepared statements   -     using traversable - OK

SQLite:

 emulated prepared statements - not using traversable - Issue exists
 emulated prepared statement  -     using traversable - Issue exists



"not using traversable":

$stmt = $db->query('SELECT a, b FROM test');
while ($row = $stmt->fetch()) {
  try {
    $db->exec('INSERT INTO test(a, b) VALUES (1, 1)');
  } catch (Exception $e) {
    printf("while loop\n");
  }
}


"using traversable":

$stmt = $db->query('SELECT a, b FROM test');
foreach ($stmt as $row) {
  try {
   $db->exec('INSERT INTO test(a, b) VALUES (1, 1)');
  } catch (Exception $e) {
    printf("foreach\n");
  }
}  

Correction:

 emulated prepared statements - not using traversable - Issue exists
 emulated prepared statement  -     using traversable - Issue exists

Does this still exist? If so, update the version properly.. ;)

Using Windows snapshots, verified that the bug still exists in 5.2.10-dev and 5.3.0RC2-dev . Cannot test with 6.0.0-dev, the php.exe doesn't even properly start.

I have a simpler test case, one solution/explanation and one workaround.
Tested under:
Windows - PHP 5.2.13 (cli) (built: Feb 24 2010 14:32:32)
FreeBSD - PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Feb 24 2010 23:12:45)

Demonstration code:
-------------------

<?php
#
# PDO foreach exception bug
# Demonstration code
# Author: Gregory Karpinsky, http://www.tiv.net
# 2010-05-06

print '<p>This code works OK (Exception is cleaned artificially)</p>';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
	try {
		$conn->query( 'Bogus SQL' );
	} catch (PDOException $e) {}
	if ( $conn->errorCode() ) {
		$conn->query( "select 'CLEAN_PDO_ERROR'" );
	}
print '<p>NO exception will be thrown.</p>';
}

print '<p>This code works OK (two separate connections)</p>';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn2 = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$conn2->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
	try {
		$conn2->query( 'Bogus SQL' );
	} catch (PDOException $e) {}
print '<p>NO exception will be thrown.</p>';
}


print '<p>This code throws unexpected exception in foreach</p>';
$conn = new PDO( 'mysql:host=localhost', 'test', 'test' );
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$oRS = $conn->query( "select 'OK'" );
foreach ( $oRS as $row ) {
	try {
		$conn->query( 'Bogus SQL' );
	} catch (PDOException $e) {}
print '<p>Exception will be thrown after this...</p>';
}
?>

Correction:
-----------
if ( $conn->errorCode() ) {

should be

if ( $conn->errorCode() !== '00000' ) {

Looking at pdo_mysql extension source code, I see the exception is actually being raised twice, not being buffered.

from php5.2.13 source, file ext/pdo_mysql/mysql_statement.c is calling _pdo_mysql_error() in two places.  Once from line 218 in pdo_mysql_stmt_execute() after mysql_real_query() fails, and then again at line 425 in pdo_mysql_stmt_fetch() because mysql_errno() indicates there is an error.

From: http://dev.mysql.com/doc/refman/5.0/en/mysql-errno.html

   "Note that some functions like mysql_fetch_row() don't set mysql_errno() if they succeed."

And: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html

   "Note that error is not reset between calls to mysql_fetch_row()"
-----------------------------------------------------------------------------
Since all the SELECT'd rows are fetched ok, the error from the botched insert is still hanging around for mysql_errno() to find, and raise the exact same exception after the data is finished being iterated.

I've attached a patch "fix-mysql_statement.c-5.2.13.patch" to resolve this problem.

From: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html

   "When used after mysql_store_result(), mysql_fetch_row() returns NULL when there are no more rows to retrieve. When used after mysql_use_result(), mysql_fetch_row() returns NULL when there are no more rows to retrieve or if an error occurred"

The patch simply does not raise an exception during a NULL result from mysql_fetch_row() since it only indicates the exhaustion of data.

The condition added simply matches the use of either mysql_use_result() or mysql_store_result() called in pdo_mysql_stmt_execute().  When not buffered, mysql_use_result() is called.  Therefore, the same check is performed after the fetch before deciding to raise an exception.

Also, when un-buffered queries are used, the test script above would be invalid as you cannot perform another operation on a result-set when not all of the results have been retrieved.

The patch was created against the released PHP 5.2.3 source code tarball.  It's so small, you should be able to modify it easily for any version of the mysql_statement.c file.

Please try a 5.3 snapshot.

Not a MySQL specific issue thus it should not be assigned to mysql, see my earlier comment:

[2008-07-03 14:37 UTC] uw@php.net
No comment on the cause just some observations. Issue exists with SQLite as well. 
[...]

Problem still exists in PHP 5.3 snapshot 201101041530

Patch uploaded to account for the changes in mysql_statement.c since the last time I patched PHP 5.2

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.