Errors handling in web services: Difference between revisions
From MoodleDocs
No edit summary |
|||
| Line 1: | Line 1: | ||
{{stub}} | {{stub}} | ||
== | ==Exceptions == | ||
Exceptions are caught by the server that generate its own error format. For example in REST: | |||
<code xml> | <code xml> | ||
| Line 12: | Line 12: | ||
</EXCEPTION> | </EXCEPTION> | ||
</code> | </code> | ||
All exceptions contain a translated message + debuginfo. | |||
== Error messages == | |||
* 16 functions: only throw exception | |||
* 2 functions: the web service function catches some exceptions and return a string error message for each faulty element (create notes / send messages) | * 2 functions: the web service function catches some exceptions and return a string error message for each faulty element (create notes / send messages) | ||
| Line 17: | Line 23: | ||
* 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. The token script returns just an error message. | ||
=== | === Issues === | ||
* clients can not match the function error because message error could be translated | |||
* web service functions are not consistent: some never return error message (exception is thrown and all transaction are rollbacked), and some bypass DB failure returning an error message (mostly linked to an id). | |||
== Suggestion == | == Suggestion == | ||
Revision as of 04:20, 10 April 2012
Exceptions
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.
Error messages
- 16 functions: only throw 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.
Issues
- clients can not match the function error because message error could be translated
- web service functions are not consistent: some never return error message (exception is thrown and all transaction are rollbacked), and some bypass DB failure returning an error message (mostly linked to an id).
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.
