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
CoreDSL currently has no notion of actions which can fail, whereas in the physical systems CoreDSL aims to model, these actions can indeed fail. The most prominent example for this are standard memory accesses.
For ETISS, I implemented an error handling mechanism with utilizing existing CoreDSL functionality. The one big downside of this mechanism is its intransparency, error handling is done at a completely different location than the actual action which can cause an error.
A try ... catch construct would solve these issues in the grammar, allowing very easy description of a block of code that can fail, and what to do if it does fail:
CoreDSL currently has no notion of actions which can fail, whereas in the physical systems CoreDSL aims to model, these actions can indeed fail. The most prominent example for this are standard memory accesses.
For ETISS, I implemented an error handling mechanism with utilizing existing CoreDSL functionality. The one big downside of this mechanism is its intransparency, error handling is done at a completely different location than the actual action which can cause an error.
A try ... catch construct would solve these issues in the grammar, allowing very easy description of a block of code that can fail, and what to do if it does fail:
This issue is mainly meant to be a collection of ideas of whether this idea is feasible, and if so, how could it be implemented in the grammar.
Questions that immediately come to mind:
finally
/else
blocks?The text was updated successfully, but these errors were encountered: