Inconsistencies in services_error and hook_server_error

Events happening in the community are now at Drupal community events on www.drupal.org.
jhl.verona's picture

This discussion has been transferred to the issue queue: http://drupal.org/node/806856

There seems to be a (surprising) inconsistency between the parameters for the function services_error and the various hook_server_error implementations, particularly xmlrpc_server_server_error.

If the services_error function is defined as (services.module, line 240, CVS Tag DRUPAL-6--2-2):
function services_error($message, $code = 0, $exception = NULL)
and also calls the various hooks with all three parameters, I do not understand why the xmlrpc_server implementation ignores the $code value in its definition (xmlrpc_server.module, line 62, CVS Tag DRUPAL-6--2-2):
function xmlrpc_server_server_error($message)
when it could easily accept a $code value which would be returned as the faultCode in the XMLRPC specifications.

This function seems to attempt to extract the error code from the message, however most of the services functions supply the error code (usually a HTTP error code) as the second parameter, with the result that using the XML-RPC server these are lost, and a generic error code of 1 (one) is returned.

The REST server accepts all three parameters, whereas the JSON Server only accepts the $message parameter.

As far as the XMLRPC server is concerned, I will be happy to supply a patch which adds the second parameter, while maintaining the original functionality, such as:

function xmlrpc_server_server_error($message, $code = 0) {
  if (!is_array($message)) {
    $message = (array)$message;
  }

  $message = implode(' ', $message);

  if ($code === 0) {
    $matches = array();
    if (preg_match("/#(\d+)/", $message, $matches)) {
      $code = $matches[1];
    }
    else {
      $code = 1;
    }
  }

  return xmlrpc_error($code, strip_tags($message));
}

Rather than add to the issue queue I wanted to check first with the community, in case I have missed some obvious reason for this inconsistency, or that my suggested patch doesn't make sense - or worse, changes the behaviour of the original function.

Best regards,

John

This discussion has been transferred to the issue queue: http://drupal.org/node/806856

Services

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: