Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Having the clearest possible Exception system #11

Open
ghost opened this issue Aug 27, 2015 · 1 comment
Open

Having the clearest possible Exception system #11

ghost opened this issue Aug 27, 2015 · 1 comment

Comments

@ghost
Copy link

ghost commented Aug 27, 2015

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

@ghost
Copy link
Author

ghost commented Oct 8, 2015

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

@ghost ghost closed this as completed Oct 8, 2015
@ghost ghost reopened this Oct 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants