conv: use errors instead of logger for convertors #60
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The exporter and importer types have a logger that is used for issuing warnings and errors. The idea was to continue conversion even if some parts of the blueprint were incorrect.
This patch changes that for the exporter to return errors instead of logging them. The importer will be changed in a follow-up patch.
I am taking a hybrid approach with errors - errors are collected in the two main functions (top-level exporting function and customization function) and joined using
errors.Join. This means is when an error occurs, the process will continue and finish off the conversion and then the error(s) are returned. Also I make an effort to return data that are still valid in case something is going on, for example inexportUserCustomizationwhen converting more than one ssh key (or keyboard layout).I just cannot get rid of a feeling the convertor should still be a little bit of a "code compiler" experience - when it encounter one error, it does not mean it stops parsing. Modern compilers will go further and try to identify as many problems as possible as long as the error is not fatal (like a missing bracket).
Anyways, if you insist on a strict approach, and something is telling me you will, then I will simply change the code to just return single error and do normal Go error checking everywhere. This will probably render all "invalid" conversion testdata a bit irrelevant - it will always render to one error which is fine I guess.