Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling multiple errors #602

Open
Xophmeister opened this issue Aug 24, 2023 · 0 comments
Open

Handling multiple errors #602

Xophmeister opened this issue Aug 24, 2023 · 0 comments
Labels
epic: usability-end-users Relates to the usability of Topiary for endusers to use Topiary as a generic "good enough" formatter P3 minor: not priorized type: feature request

Comments

@Xophmeister
Copy link
Member

There are a number of improvements that could be made to the handling of multiple errors, which may arise during concurrent formatting:

  • The CLIError::Multiple variant is used to capture any number of failures from concurrent tasks (except when there is only one task). While the original error is logged when it happens, it is then discarded to collapse into this "all-or-nothing" error. This variant could be changed into Multiple(Vec<TopiaryError>), to keep track of the original errors. This raises a number of questions:

    1. How does one implement Error::source for this variant?
    2. What do we do with this variant, when we need to handle it? (e.g., It seems redundant to write it out to the logs again.)
  • During concurrent formatting, if any task fails (and there is more than one task), then Topiary will log that multiple errors have occurred and exit with a non-zero exit code. This might not be a reasonable default: rather, this behaviour should be behind a CLI flag (e.g., --fail-on-multiple). Alternatively, this behaviour could remain the default, but with the option to disable it (e.g., --no-fail-on-multiple).

  • During concurrent formatting, it may be useful to allow Topiary to bail out on the first failure, rather than continuing with its other concurrent tasks until they've all finished/failed. This should be enabled through a CLI flag (e.g., --fail-fast).

💡 This issue depends on #583.

@Xophmeister Xophmeister added the P3 minor: not priorized label Aug 24, 2023
@ErinvanderVeen ErinvanderVeen added the epic: usability-end-users Relates to the usability of Topiary for endusers to use Topiary as a generic "good enough" formatter label Sep 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic: usability-end-users Relates to the usability of Topiary for endusers to use Topiary as a generic "good enough" formatter P3 minor: not priorized type: feature request
Projects
None yet
Development

No branches or pull requests

2 participants