The attached patch fixes this by not throwing the warning if EG(exception) is not NULL. IMO the warning should be removed completely (because it's superfluous, and I don't see offhand how it can be triggered other than by an exception, but I don't know PHP core at all), but it's easy to tweak my patch into doing that instead; this patch is just the minimal solution.

Something I forgot to mention in the original report:

Using @array_map(...) suppresses the warning. However, it also suppresses any other notices or warnings that might happen in the callback. That's why I put the $foo = $bar['baz']; bit in barf(): if you use @array_map, the "Undefined variable" notice, which is legitimate, goes away as well.

More generally, @ is kind of a blunt instrument that often suppresses more than you expect it to, masking mistakes.

I was wondering what kind of situation needs throw a exception in map function?

and why doing that? thanks

Basically what I'm doing is

implode("\n", array_map('readStyleFile', $files)

where $files is an array of file names, and readStyleFile() can throw an exception if something is wrong (in this case it's if the file doesn't exist, but other cases are imaginable). This exception then propagates up a few levels and is caught and handled. Throwing an exception from inside the map callback works just fine: it stops the callback, stops array_map(), propagates up to the caller of array_map(), then works its way up the call stack like any other exception. The only issue is that warning that won't go away.

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94433 has Roan's actual use case.

I've just come across this too and I'm really surprised at this inconsistent behavior, for me the question isn't "what kind of situation needs throw a exception in map function" but "why would the map function behave differently to any other situation".  If you change array_map to array_walk in the original example then the exception propagates upward, as expected.

At the very least, I'd expect to see a note on the PHP manual page warning users that exceptions work differently for the callback parameter to array_walk.

Unfortunately I have the same problem on PHP 5.5.16 from Ondrej's PPA (Ubuntu 14.04). This is an inconsistent behavior as other functions like array_walk() or array_reduce() don't do that.

Note that this same issue happens for array_reduce and array_filter, but not array_walk.

The same odd behaviour is in SQLite3 where the code below gives the output:

PHP Warning:  SQLite3::querySingle(): Unable to execute statement:  in /test/src/exceptionTest1.php on line 11
Exception: test exception


<?php
function my_udf_md5($string) {
    throw new \Exception("test exception\n");
}

$db = new SQLite3('mysqlitedb.db');
$db->createFunction('my_udf_md5', 'my_udf_md5');

try {
    $result = $db->querySingle('SELECT my_udf_md5("test")');
    var_dump($result);
}
catch(\Exception $e) {
    echo "Exception: ".$e->getMessage();
}