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

Semantic error messages #8646

Open
rarkins opened this issue Feb 11, 2021 · 6 comments
Open

Semantic error messages #8646

rarkins opened this issue Feb 11, 2021 · 6 comments
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:refactor Refactoring or improving of existing code

Comments

@rarkins
Copy link
Collaborator

rarkins commented Feb 11, 2021

I'd like for our error handling to be more robust and thinking of ways in which we can control:

  • Errors which mean we should abort the whole run (e.g. disk space, authorization)
  • Errors which mean we should abort the repo (config error, git changed, etc)
  • Errors which mean we should abort the branch (e.g. PR we thought is open is actually closed)

One possibility would be that instead of throwing new Error(X) we could have classes of errors e.g. mapped to the above. Something like this could mean we have less string-checking of error messages in our error handling and instead can know whether to pass it up or log and consume it.

Another thing I need from the app perspective is to know which repo-level errors are "permanent" - e.g. disabled by config, a fork, etc.

@rarkins rarkins added type:refactor Refactoring or improving of existing code status:requirements Full requirements are not yet known, so implementation should not be started priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others labels Feb 11, 2021
@pret-a-porter

This comment was marked as outdated.

@rarkins

This comment was marked as outdated.

@pret-a-porter

This comment was marked as outdated.

@rarkins

This comment was marked as outdated.

@pret-a-porter

This comment was marked as outdated.

@rarkins
Copy link
Collaborator Author

rarkins commented Dec 20, 2022

https://github.com/ehmicky/modern-errors

@rarkins rarkins added status:ready and removed status:requirements Full requirements are not yet known, so implementation should not be started labels Oct 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:refactor Refactoring or improving of existing code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants