Errors handling in web services: Difference between revisions
From MoodleDocs
No edit summary |
|||
Line 2: | Line 2: | ||
==Exceptions == | ==Exceptions == | ||
=== Format === | |||
Exceptions are caught by the server that generate its own error format. For example in REST: | Exceptions are caught by the server that generate its own error format. For example in REST: | ||
Line 21: | Line 23: | ||
== Error messages == | == Error messages == | ||
=== | ===Format === | ||
<code php> | <code php> | ||
/** | /** |
Revision as of 04:14, 24 April 2012
Exceptions
Format
Exceptions are caught by the server that generate its own error format. For example in REST:
<?xml version="1.0" encoding="UTF-8"?>
<EXCEPTION class="invalid_parameter_exception">
<MESSAGE>Invalid parameter value detected</MESSAGE>
<DEBUGINFO></DEBUGINFO>
</EXCEPTION>
All exceptions contain a translated message + debuginfo.
When to send an exception
- DB WRITE functions must rollback when an exception is raised. We usually throw back the exception to the server.
Error messages
Format
/**
* Creates a warnings external_multiple_structure
* @return external_multiple_structure
* @since Moodle 2.3
*/
private static function warnings() {
return new external_multiple_structure(
new external_single_structure( array(
'messageid' => new external_value(PARAM_INT, 'message id is a string that can be parsed by the client developer to find out what kind of error is it. For example: 'userdoesntexist),
'debugmessage' => new external_value(PARAM_TEXT, 'a not translated debug message to help the client to know straight away what is the issue'),
'element' => new external_value(PARAM_TEXT, 'element'),
'elementid' => new external_value(PARAM_INT, 'element id'),
), 'warning'), 'list of warnings'
);
}
When to send an error message
TODO