View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005787 | Taler | obsolete component | public | 2019-06-30 23:07 | 2019-12-20 19:11 |
| Reporter | Marcello Stanisci | Assigned To | Marcello Stanisci | ||
| 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 23:07 | Marcello Stanisci | New Issue | |
| 2019-06-30 23:07 | Marcello Stanisci | Status | new => assigned |
| 2019-06-30 23:07 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2019-09-16 09:49 | Christian Grothoff | Relationship added | related to 0005788 |
| 2019-09-16 09:50 | Christian Grothoff | Product Version | => git (master) |
| 2019-09-16 09:50 | Christian Grothoff | Target Version | => 0.6 |
| 2019-09-21 19:22 | Marcello Stanisci | Note Added: 0014928 | |
| 2019-09-25 11:45 | Marcello Stanisci | Note Added: 0014956 | |
| 2019-09-29 14:24 | Marcello Stanisci | Note Added: 0014969 | |
| 2019-11-11 17:42 | Marcello Stanisci | Note Added: 0015072 | |
| 2019-11-11 17:42 | Marcello Stanisci | Status | assigned => resolved |
| 2019-11-11 17:42 | Marcello Stanisci | Resolution | open => fixed |
| 2019-11-14 22:38 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-12-20 19:11 | Christian Grothoff | Status | resolved => closed |
| 2022-08-23 20:26 | Christian Grothoff | Category | bank (demonstrator) => py bank (demonstrator, obsolete) |
| 2023-12-03 01:23 | Christian Grothoff | Category | py bank (demonstrator, obsolete) => obsolete componet |
| 2023-12-11 20:08 | Florian Dold | Category | obsolete componet => obsolete component |
