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

Solidify and generalize error handling code in the runtime #1175

Open
Licenser opened this issue Aug 11, 2021 · 2 comments
Open

Solidify and generalize error handling code in the runtime #1175

Licenser opened this issue Aug 11, 2021 · 2 comments
Labels

Comments

@Licenser
Copy link
Member

Licenser commented Aug 11, 2021

Error handling is a significant part of any project, historically we picked error-chain as an option for dealing with this, at the time it was the defacto standard in rust. This has changed by now and the project has grown to the point where error-chain can become cumbersome and maintain as an error handling framework. This project aims to solve this problem by taking the time to investigate alternatives and reset error handling to a fresh start.

This comes with a few requirements:

  1. Errors need to be helpful for users, this is the main priority.
  2. Errors should be easy to add - in the past string errors have quickly crept in since adding new error cases was complicated and effort-intensive - simplifying this will lead to better maintainability
  3. Support for hygienic errors especially for script failures (pointing to the location in the code) and hints
  4. Support for structured logging
  5. Accessibility - we should present errors in a way that is accessible to all users
  6. Good cross crate support - the codebase includes a number of crates and we will need to be able to handle errors sensibly over crate boundaries
  7. Performance is quite relevant, the error framework can not slow down execution on the hot path
  8. A library or framework should be well maintained in the hope that it is long-lasting
  9. Async support, while error handling is likely not affected by this it is worth keeping in mind since a lot of our code is async based
  10. Ideally, error propagation and attribution to call paths would be helpful in many situations
  11. Very optional, an ‘issue’ database, to link issues id’s to

A few related issues are:

Possible frameworks that have come to mind are (this is a non-exhaustive list):

  • ariadne
  • eyre (and color_eyre)
  • anyhow
@Licenser Licenser added enhancement New feature or request accessibility labels Aug 11, 2021
@anonymousr007
Copy link

Hi @Licenser , I am Rishabh,Final year computer engineering student at Delhi Technological University.I wanted to say that I am interested in this project. I am intermediate c++ Developer and have good knowledge of Data Structures and Algorithms and also I know basics of rust language.Can you please tell me about the prerequisites for this project in LFX Mentoship program except than Rust programming language.

Thanks & Regards
Rishabh

@Licenser
Copy link
Member Author

Licenser commented May 5, 2023

unassigning this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants