Errors of type E_USER_ERROR, thrown by service_error(), are currently not returned if you change the error level of the amfphp module to E_ERROR. However, this does not allow the Flash frontend anymore to give the end user some reasonable clues about what went wrong.
For example, registering a user with user.save with a username that already exists, will just return NULL now. When you put the error level to E_ALL ^ E_NOTICE it returns something more useful:
array(5) {
["description"]=>
string(197) "The name <em>testerdetest</em> is already taken.
<p>
Het e-mailadres <em>kristof+testerdetest@statik.be</em> is al geregistreerd. <a href="/user/password">Ben je je wachtwoord vergeten?</a></p>
"
["details"]=>
string(84) "/var/www/dev-multisite/sites/dev.uitmetvlieg.be/modules/contribute/amfphp/amfphp.inc"
["level"]=>
string(18) "Unknown error type"
["line"]=>
float(74)
["code"]=>
string(20) "AMFPHP_RUNTIME_ERROR"
}
However, I do not want E_WARNING errors to be handled by amfphp as well, as some modules we are using cause E_WARNING errors (not good, I know, although it are the latest stable versions of contributed modules though) and the web service becomes unusable.
Now there is just a dropdown with two choices for error handling, but I suggest to put separate checkboxes in the settings interface for each type of PHP error, so users can just enable those specific errors they want to see.
I am willing to contribute a patch for this if there is interest.
Comments
Comment #1
japanitrat commentedI wonder if triggering an error is the way to go for all service-"error-messages" anyway .. it should only use trigger_error when there is an actual PHP exception (in which case "RUNTIME_ERROR" makes sense!) , not just some random message. It also shouldn't give sensitive information to the client (server filesystem) ..
the server_error hook of services has more arguments than the amfphp handler actually supports, maybe this should be extended to allow a more useful error handling / dispatching ...