View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005787 | Taler | obsolete component | public | 2019-06-30 21:07 | 2019-12-20 18:11 |
| Reporter | Marcello Stanisci | Assigned To | Marcello Stanisci | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0005787: Make exception handling less confusing. | ||||
| Description | Exception handling is ALL put into the middleware module, which makes hard to map exceptions to where those occur in the code. Also, the code errors are computed with a unnecessary/easy-to-break/cryptic arithmetic ([1]). Ultimately, new-comers who aren't aware of this module will naturally put their handlers NOT in that module, resulting in a mixed exception-handling style! The suggestion is to place obvious exception handlers in the middleware module (malformed JSON / "bad requests" / ..), and spread other less obvious exceptions handlers to where in the code those could be raised. [1] https://git.taler.net/bank.git/tree/talerbank/app/middleware.py#n149 | ||||
| Tags | No tags attached. | ||||
| related to | 0005788 | closed | Marcello Stanisci | Malformed JSON on POST makes bank crash. |
| 4043cac..0025956 defines custom exception objects raised when a bank account or transaction aren't found in DB; this way we can get more information when such queries fail. | |
| Also to consider: right now, the bank has multiple flavours for any type of error. For example, it defines one error code for error X generated by endpoint Y, and defines *another* error for (same) error X generated by endpoint Z. Do we really need this level of precision? The requester should always know from which endpoint it got the error. | |
| Readability improved due to removing unnecessary granularity of error codes (baee420..cba0af7). | |
| Not a bug anymore. Same style (*) used in Libeufin. *: it means all the exceptions get managed in one place of the codebase (middleware.py). | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-06-30 21:07 | Marcello Stanisci | New Issue | |
| 2019-06-30 21:07 | Marcello Stanisci | Status | new => assigned |
| 2019-06-30 21:07 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2019-09-16 07:49 | Christian Grothoff | Relationship added | related to 0005788 |
| 2019-09-16 07:50 | Christian Grothoff | Product Version | => git (master) |
| 2019-09-16 07:50 | Christian Grothoff | Target Version | => 0.6 |
| 2019-09-21 17:22 | Marcello Stanisci | Note Added: 0014928 | |
| 2019-09-25 09:45 | Marcello Stanisci | Note Added: 0014956 | |
| 2019-09-29 12:24 | Marcello Stanisci | Note Added: 0014969 | |
| 2019-11-11 16:42 | Marcello Stanisci | Note Added: 0015072 | |
| 2019-11-11 16:42 | Marcello Stanisci | Status | assigned => informing |
| 2019-11-11 16:42 | Marcello Stanisci | Resolution | open => fixed |
| 2019-11-14 21:38 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-12-20 18:11 | Christian Grothoff | Status | informing => closed |
| 2022-08-23 18:26 | Christian Grothoff | Category | bank (demonstrator) => py bank (demonstrator, obsolete) |
| 2023-12-03 00:23 | Christian Grothoff | Category | py bank (demonstrator, obsolete) => obsolete componet |
| 2023-12-11 19:08 | Florian Dold | Category | obsolete componet => obsolete component |