View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0021661 | mantisbt | code cleanup | public | 2016-09-03 20:40 | 2018-03-05 10:44 |
Reporter | cproensa | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 1.3.2 | ||||
Summary | 0021661: throw errors as exceptions | ||||
Description | Error handling is currently done with PHP error triggering, which is handled in error_api. For example: In bug-action-group, if any operation in the list of bugs fails, the whole task is stopped. By using try-catch, any error for an individual bug operation can be managed and shown to the user at the ending report. A proposal is to set up an error handling mode that throws exception instead of showing the current error page. This mode can be switched on and off, when exception-aware code is going to be used. | ||||
Tags | No tags attached. | ||||
related to | 0021595 | new | When a filter generates a bad query, reset the filter |
@cproensa, you might be interested in having a look at a branch which has been removed some while ago. |
|
I see there is doing a full refactor to exception handling. @atrol see this proof of concept, applied to bug_actiongroup |
|
I'm on board with moving towards exceptions. I would appreciate a solution that achieves the following:
I suggest a slow refactor where we have classes for our entities that does the ORM + exceptions. Then have the existing APIs provide the same behavior over such classes until they are no longer needed. We can then use these model classes as the foundation for our SOAP/REST API as well as our regular web page calls. Examples of such gradual refactoring including introduction of classes like MantisEnum, though it doesn't involve DB access. |
|
vboctor, that is a very long term goal, at current progression. Have a look at my proposal, which is a more short term idea:
(This exception class could be improved in the future as the parent of specific exceptions. But that is another story, as you suggested.) Think of it like the facility we currently have for error handling that bypasses ui and outputs HTTP error header. I see direct application:
|
|
Adding here something related error_api.php
EDIT: fix markdown |
|