Skip to content

Standardize and improve error reporting #1077

@Stagno

Description

@Stagno

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions