-
Notifications
You must be signed in to change notification settings - Fork 7
Description
What's needed?
The current approach when parsing components and connections and building Python objects out of them is to try to recover from errors to at least get a partial view of the component graph when necessary.
The problem is there are some use cases, when a partial component graph is not good enough, to be able to work with it we need to make sure the graph is complete and had no errors.
Proposed solution
Probably the most sensible approach would be to add a boolean to the methods like raise_on_errors, and when True, if any major_issues were collected, instead of logging the issues, an exception is raised containing these issues (and probably minor issues too) so users can also inspect them.
This should be very easy to implement.
Alternatives and workarounds
Alternatively we could add an overload where you can pass a list to collect the issues, if None is passed, issues are logged. But this interface seems more hacky and less Pythonic.
Future improvements
In the future we could improve error reporting to be more easily to interpret programatically, for example using enums, or specific exceptions and exception groups, include the protobuf message in case the user wants to inspect it, etc.
This should probably be delayed to when the common code is moved to https://github.com/frequenz-floss/frequenz-api-common/ though.