[MGNLFORM-19] Review exception handling with FormProcessors Created: 04/Jun/09 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia Form Module |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | Magnolia International | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Task DoR: |
Empty
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
It might not be related directly to the form processors; but the newsletter's implementations for instance, catch all exception thrown in their business logic code, and log them. There is no way for the actual error to bubble up to the form rendering (i.e form error messages seem static while they could be more dynamic). As a result, these exceptions are lost, and the processor has to log it. |
| Comments |
| Comment by Magnolia International [ 04/Jun/09 ] |
|
See the log extract in attachment. These are 2 different stacktraces, while the first one should "ideally" be nested in the second one (if the latter was useful at all) |
| Comment by Magnolia International [ 29/Jul/09 ] |
|
The original aim of this issue report was to do an actual code review and possibly change how exceptions are handled and passed around (or not); hence the fix version set 1.1. |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |