Provide a DSL behavior aware error reporting service in GEMOC

[dvojtise]

One of the activities a language designer has to do is to handle how a model execution should behave when the provided model is incorrect.

One way is to statically check it (using contraints), even if this is a good practice, this not always possible (for example with external event which may produce a stop of the execution), or it might be simpler to crash at runtime rather than try to check all possibilities, or the designed dsl is dynamically typed (thus the early stage check is just impossible)

The second way is to stop the model execution and report the error to the user (ie. the model designer). One simple implementation is to use the underlying implementation language exception mecanism. Actually, this is not the expected level of details from the model designer point of view. since the exception will have in its stacktrace elements not related to the @step (for example intermediate call to methods related to implementation details that are useful only for the language designer).

Currently ALE has no Exception concept (https://github.com/gemoc/ale-lang/issues/37), but more than such concept what I really expect is a kind of service that would take into account GEMOC concepts to provide an error to the model designer. It should show a report of the status of the model when it crashed with:

• a user readable message
• a stacktrace that shows only declared Steps (ie. other methods call are ignored or hidden), this trace should should method call AND involved model elements
• a snapshot of the runtime data
• information about the engine (ie. in a concurrent engine, some specific data about other step might be interresting too)

The Ui would then present this according to the run mode. In debug, I expect a graphical presentation of most of this. In test/scenario run mode, I expect a fully textual output. Additionaly, in debug mode, may be we can have a language designer/model designer switch allowing to show hide intermediate "non step" calls.

Most of the required data are actually available in the engine and the trace addon, so this service should probably be realted to them.

[szschaler]

One note on this: some engines (e.g., my Henshin engine) don't actually have a notion of operation calls, but progress through the operational semantics through rewrite rules (and there may be other ways). Would it be possible to ensure any new features in GEMOC don't further entrench the assumption of operations-based semantics?

[dvojtise]

Sure My point was exactly going that direction: from the end user (model designer ) point of view, she doesn't really care about the engine and the language used to write the semantics (k3, ale, xmof, Henshin), but she does care about observable Step (ie. step, step into) of the designed DSL semantic. Only the language designer may be interested in the "native" execution stack used by the engine.

This is up to the engine (and its underlying implementation language) to provide any relevant information. for example in the concurrent engine (https://github.com/eclipse/gemoc-studio-execution-moccml/) the stacktrace is flat (ie. no nested call) as all operations ( can be seen as kind of rewrite rule too ?) are atomic and orchestrated by the solver. The stored execution trace (https://github.com/eclipse/gemoc-studio-modeldebugging/tree/master/trace) will contain more ParallelStep than SmallStep as opposed to an operation based engine such as K3 or ALE which will have a lot of SmallStep and no ParallelStep.

By the way, (in order to take it into account) how does a henshin stacktrace look like ? (ie. on a crash, what is reported to the henshing user (language designer) about the transformation rule that crashed and its context ?)

[szschaler]

Good question. At the moment, I think, the likely thing to happen is that none of the rules in the operational semantics match and so the debug stops right away (or prematurely) stating that there is nothing left to do. Alternatively, a rule might match, but produce an unexpected result because an assumption made by the rule designer was violated. In that case, the debug session goes off in a weird direction :-)

There is no notion of "crash" or "throwing an exception" as that's not something that can happen in a graph-transformation system. Anything like this would have to be explicitly modelled in the language, I guess, making it a first-level concept of the new modelling language. Then, we could write rules in our operational semantics that explicitly describe the error-handling behaviour of the language.

[dvojtise]

Maybe my use case may help to sort it out.

My DSL has a StateMachine part with guards. These guards use Expression (also used in several other parts of the DSL) but actually, expressions may return boolean or other types (String, integer and so on). If the user's model put an expression that does not end up in a boolean (another type, or even worse division by zero), the guards should trigger this special behaviour: ie. ask GEMOC to end and show its current state the best possible way.

[szschaler]

I would argue that this needs to be modelled in the operational semantics itself – there is no notion of an exception in a graph transformation: a rule either matches and then can be executed or it doesn’t, in which case nothing happens. This nothing may be because the type of an expression value isn’t right or because there simply isn’t anything to be done any more. If you want to differentiate these cases, you need to explicitly model “errors” in your language. You may wish to produce a generic model of what errors are and weave this into concrete xDSMLs, but it would still need to be explicitly modelled somewhere. This would probably reflect as some data in the model, which could then be picked up by the execution engine to produce some sort of “stack trace”, assuming we define a standard for how errors are represented in the model.