You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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
orSyntacticError
exceptions) and internal compiler faults. In practice, some errors might still not be categorized correctly.Here are some improvements to consider:
std::runtime_error
, assertions and throwingLogicError
, 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.throw
,DAWN_ASSERT
,assert
,exit != 0
, ...), decide what is the correct category and implement the corresponding standardized reporting.dawn4py
API the exceptions/errors are correctly translated into python ones and the error reporting is essentially the same wrt using the CLI tools.The text was updated successfully, but these errors were encountered: