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

Standardize and improve error reporting #1077

Open
4 tasks
Stagno opened this issue Dec 2, 2020 · 2 comments
Open
4 tasks

Standardize and improve error reporting #1077

Stagno opened this issue Dec 2, 2020 · 2 comments
Labels

Comments

@Stagno
Copy link
Contributor

Stagno commented Dec 2, 2020

The recent workshop showed that we can do much better in reporting errors to the DSL user.

We currently already distinguish, in theory, between errors that are due to incorrect input SIR/IIR (SemanticError or SyntacticError exceptions) and internal compiler faults. In practice, some errors might still not be categorized correctly.

Here are some improvements to consider:

  • Choose how to handle internal compiler faults (currently it's a mix between throwing std::runtime_error, assertions and throwing LogicError, but I might have missed other ways). Ideally one way should be chosen. Let's keep in mind that the purpose of reporting these errors to the user is that the user, in turn, should report those to us, as he/she isn't "responsible" for the error. So it's crucial that the reporting contains at least the line of (dawn) code that failed and the stack trace.
  • Standardize also semantic/syntactic errors to report to the user what's strictly necessary to fix the input code, e.g. line and column in the original DSL script, elements involved (fields, ops, etc.), the most precise textual description of the problem. Omit line of (dawn) code throwing and stack trace (not interesting to the user). Prerequisite: dusk must report correct line&column info...
  • Go through all the errors (throw, DAWN_ASSERT, assert, exit != 0, ...), decide what is the correct category and implement the corresponding standardized reporting.
  • Make sure that when calling the dawn4py API the exceptions/errors are correctly translated into python ones and the error reporting is essentially the same wrt using the CLI tools.
@Stagno Stagno added enhancement backend dawn related labels Dec 2, 2020
@BenWeber42
Copy link
Contributor

Just to make sure we don't forget: I believe there were also cases where a Release build generated C++ code even though it should have crashed because of semantically invalid SIR.

@Stagno
Copy link
Contributor Author

Stagno commented Dec 10, 2020

Just to make sure we don't forget: I believe there were also cases where a Release build generated C++ code even though it should have crashed because of semantically invalid SIR.

That's because of assertions, they are not evaluated in release mode. Reporting of semantic/syntactic errors should be done through exceptions instead.

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

2 participants