-
Notifications
You must be signed in to change notification settings - Fork 28
Open
Labels
Description
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 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. - 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.