Recent Changes - Search:

Documents

Community

Related Projects

Powered by PmWiki

Error handling

Several errors can happen during communication with a remote web service, such as:

  • Remote server is unavailable
  • Supplied url is not a Hessian service
  • Corrupted data (results in a parsing error)
  • Unexpected conditions in programming and others.
  • The Hessian protocol defines errors as Faults and they represent adverse conditions in the remote service that can be sent as part of a reply.

When an error is detected, HessianPHP sets the value of the error() function of the Hessian class to an object that represents the error. Using the errorReporting() function you can configure how HessianPHP submits errors to the user, see the user guide for more information.

Error objects can be one of these two:

HttpError for communication errors containing a message from the remote server, an HTTP code and headers and whatever was printed by the remote server in the reply.

HessianError which usually happens when there is a parsing error or when the remote service returned a Fault as a reply. It contains a message and a code of the error. Optionally can have an object representing the detail of the error. Java services usually return a stack trace of the remote exception that is formatted as an array by HessianPHP. You can catch a generic Exception object or try the specific exceptions mentioned above like this (gather all information about errors and print it out):

try{    
  $proxy = new HessianClient($testurl);    
  $val = $proxy->addUser( new Usuario("Manolo","Gómez",777) );
} catch(HttpError $ex) {
  echo "Exception: " . $ex->getMessage()."\n";
  echo "Code: " . $ex->getCode()."\n";    
  echo "Headers: ". var_dump($ex->getHeaders(),true);    
  echo "Reply body: " . $ex->getBody()."\n";
} catch(HessianError $ex) {
  echo $ex->getMessage()."\n";    
  echo $ex->getCode()."\n";    
  var_dump($ex->getError());
}

Introduction of exceptions in PHP5 eases error handling enormously, allowing the normal flow of the script to continue if it's needed.

NOTE: Before publishing an object as a web service with HessianPHP, it is highly encouraged that developers test the object thoroughly and make sure it doesn't print anything to the standard output, this means don't use echo or print to debug an object once it has been published. Because HessianPHP uses the standard output to print the reply to the caller, if PHP triggers a warning or a notice, it will also get printed on the screen, which will corrupt the reply.

In order to completely avoid this behavior, you can deactivate error reporting in php.ini or by calling error_reporting(0) at some point at the beginning of the script. Note that this will only hide the error and there is a chance that an exception is still thrown in the client if the service writes an incomplete or empty reply.

About PHP error_reporting()

Because of changes in the default behaviour of newer PHP versions, functions that return a reference (using the & operator) will raise a Notice warning if a value type is returned (like ints, bools, strings, etc.).

This directly affects the parser component of HessianPHP since the parseObject() function might return an object or a value depending on the input and if an object is returned, then it has to deal with possible object references in the very the incoming stream as the protocol specification states.

The result is that this notices thrown by PHP physically corrupt the output of HessianPHP Services and polute the output of clients since parseObject() is heavily used in the parser. In order to mitigate this, both client and service classes have a new default behaviour since RC2.

By default, HessianService will switch PHP's error reporting to E_ALL ^ E_NOTICE when an object is published.

On the other hand, HessianClient uses a global filter called PHPErrorReportingFilter that disables notices before any remote call and switches back to whatever value error_reporting had before. This filter can be disabled if you want to control error_reporting() by yourself, although is not recommended.

For more information about filters see Filters

Edit - History - Print - Recent Changes - Search
Page last modified on December 31, 2005, at 06:12 AM

PmWiki can't process your request

Cannot acquire lockfile

We are sorry for any inconvenience.