ghost
commented
9 years ago there is now in the soon-to-be-merged branch a lot of
throw ErrorTypeX;
or
throw ErrorTypeY('thatpublicinfo', 'thatprivateinfo');
they all inherits from the ErrorResponse class which extends \Exception.
This Exception system pairs with \API\Core\Tool::makeEndpoint(), to separate the error code (in fact, string) that is sent to the user, and the error code (in fact, string) that is logged in Apache (yes Apache, see README.md, nginx support is dying).
The current exceptions :
https://github.com/glpi-project/plugins/tree/user_registration/api/src/exceptions
My source of inspiration for this stuff are the Decorators (like the ones in Python), the imitation of that is made via PHP's call_user_func_array() which worked very fine and was very helpful associated with PHP's anonymous functions that the Slim Framework "controller methods" use (there is no controller in Slim).
User could have a 500 with
{"error": "SERVICE_ERROR"}Json object,
While, is server-side-logged the line, and message from the \Exception that was thrown.
In fact ServiceError is a special one, that is covering any \Exception thrown in the controllers.
For the other specific Exceptions that are thrown (e.g: ResourceNotFound('Plugin', 'unexistingplugin') ), some requires parameters, some don't, some parameters are public, some aren't.
There is one problem that still need to be fixed, concerning the exceptions or errors that occurs outside of the "decorated" anonymous function, which actually sends a ol'dirty default slim framework page
ATM the error handling mechanism is not well defined, in terms of Exceptions. It would be nice to make use of exception classes to define every possible error, that are likely to happen during request