[MAGNOLIA-6090] Handle and aggregate errors in config source operations Created: 18/Feb/15 Updated: 22/Dec/16 Resolved: 22/Dec/16 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | configuration |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Neutral |
| Reporter: | Aleksandr Pchelintcev | Assignee: | Unassigned |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoR: |
Empty
|
||||||||||||
| Date of First Response: | |||||||||||||
| Epic Link: | Registry & Resources API wishlist | ||||||||||||
| Story Points: | 5 | ||||||||||||
| Description |
|
Former issue title: Typical cases:
|
| Comments |
| Comment by Magnolia International [ 29/Jul/15 ] |
|
Not convinced exceptions are the way to go. I'm assuming you'd want different types to do proper problem reporting (e.g with a certain type you'd need to path of the file in the error, stuff like that ?). Consider other approaches, e.g a more lightweight "Problem" object which encapsulates the type of problem (inherently by its type, or by an enum attribute maybe), and additional relevant properties (messages, locations, etc); on the top of my head though we already have most of the info in the definition metadata. (so info.magnolia.config.registry.DefinitionProvider#getErrorMessages could provide e.g a List<Problem> instead of List<String>. |