Errors handling in web services: Difference between revisions

Revision as of 07:31, 9 March 2012

This article is a stub. Please help improve Moodle Docs by editing it and adding some content.

Current Moodle web services error handling

16 functions: all 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>

2 functions: the web service function catches some exceptions and return a string error message for each faulty element (create notes / send messages)

download/upload script return string error message (JSON) + error code. The token script returns just an error message.

Main issue

it is difficult for client to programmatically know which exception is raised. It is difficult to display an accurate.

Suggestion

I think the web service developer still should choose if he wants to return an error message or an exception. The developer should still follow the rule about DB WRITE functions that must rollback when an exception is raised. We usually throw back the exception to the server.

The goal being to let the developer write his own error message, we should add some code error to all exceptions or messages.

@@ Line 1: / Line 1: @@
 {{stub}}
-I'm looking at how we return errors in the current Moodle web services. Here is the status:
+==Current Moodle web services error handling==
-* exceptions are raised: 16 functions
+* 16 functions: all exceptions are caught by the server that generate its own error format. For example in REST:
-REST:
 <code xml>
 <?xml version="1.0" encoding="UTF-8"?>
@@ Line 13: / Line 12: @@
 </EXCEPTION>
 </code>
-XMLRPC/SOAP: respective error format
+* 2 functions: the web service function catches some exceptions and return a string error message for each faulty element (create notes / send messages)
-* string error messages: 2 functions (create notes / send messages)
+* download/upload script return string error message (JSON) + error code. The token script returns just an error message.
-* download/upload script return string error message (JSON) + error code
+=== Main issue ===
+it is difficult for client to programmatically know which exception is raised. It is difficult to display an accurate.
+== Suggestion ==
+I think the web service developer still should choose if he wants to return an error message or an exception. The developer should still follow the rule about DB WRITE functions that must rollback when an exception is raised. We usually throw back the exception to the server.
+The goal being to let the developer write his own error message, we should add some code error to all exceptions or messages.