[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:
supersession
is superseded by MAGNOLIA-6736 Expose Map2Bean conversion errors via... Closed
is superseded by MAGNOLIA-6743 Aggregate problems during Node2Bean c... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Registry & Resources API wishlist
Story Points: 5

 Description   

Former issue title: Use/design proper exceptions for config source operations.

Typical cases:

  • N2B conversion (or other conversion) issues.
  • Yaml config source binding issues.
  • YamlReader reading issues.


 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>.

Generated at Mon Feb 12 04:11:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.