Talk:Errors handling in web services: Difference between revisions
From MoodleDocs
No edit summary |
No edit summary |
||
Line 2: | Line 2: | ||
About the exception format (https://docs.moodle.org/dev/Errors_handling_in_web_services#How_to_handle_exception_on_the_client_side): | About the exception format (https://docs.moodle.org/dev/Errors_handling_in_web_services#How_to_handle_exception_on_the_client_side): | ||
* Should 'message' be translated or not. I marked it as 'translated' | * Should 'message' be translated or not. I marked it as 'translated' otherwise it would have been a duplicate with the not translated 'debuginfo'. When it's translated it is easier to display it to the user automatically. | ||
* Could'debuginfo' have a defined structure like: code_error_string | english_human_message | | * Could 'debuginfo' have a defined structure like: code_error_string | english_human_message | some_ids_or_json_array - note that a json format would look very weird when returned by rest-xml/soap/xml-rpc. | ||
* sometimes exceptions are thrown at lower level so except if we try-catch the entire external function we can't change them. | * sometimes exceptions are thrown at lower level so except if we try-catch the entire external function we can't change them. | ||
* we can not change much of the existing web service exception without potentially breaking existing clients. | * we can not change much of the existing web service exception without potentially breaking existing clients. | ||
We really need to identify how exception/errors should be formatted in order to make the client developer job easy. |
Revision as of 03:33, 8 May 2012
Jerome Mouneyrac - 08/05/2012
About the exception format (https://docs.moodle.org/dev/Errors_handling_in_web_services#How_to_handle_exception_on_the_client_side):
- Should 'message' be translated or not. I marked it as 'translated' otherwise it would have been a duplicate with the not translated 'debuginfo'. When it's translated it is easier to display it to the user automatically.
- Could 'debuginfo' have a defined structure like: code_error_string | english_human_message | some_ids_or_json_array - note that a json format would look very weird when returned by rest-xml/soap/xml-rpc.
- sometimes exceptions are thrown at lower level so except if we try-catch the entire external function we can't change them.
- we can not change much of the existing web service exception without potentially breaking existing clients.
We really need to identify how exception/errors should be formatted in order to make the client developer job easy.