Use Case
Errors in the execution of the model can be hard to detect: They can not be detected during the compilation of the code, may depend on the environment and, if they are triggered, are seldom logged or does not contain suitable informations about the reason of this error.
Therefore this project’s aims to increase the functionality of the model execution environment by giving back messages:
Where did the error occur
Why did the error occur
What could be done to prevent the error from occurring again.
This project uses ontologies to store the informations about possible errors. Additionally this project introduces best practices to implement return codes in the AdoScript and in external programs to analyse execution states.
This program extends the ideals of semantic modelling by implementing an additional level of modelling (how exceptions and unexpected behaviour will be handled). Additionally humans will be able to handle code encountering exceptions after these have been arisen and are able to detect the source of the error.
Experiment
The goal of this experiment has been to prove that a messaging system for errors can be implemented within the AdoXX framework on the level of modelling methods. Because of the amount of possible errors or failures the experiment focused on the following points:
- The framework should be able to detect errors when no Token has been set
- The framework should be able to detect errors when no internet connection has been established
- The framework should be able to detect errors when the external programs (those implemented in the s*IoT framework) have not been started
- The framework should be able to detect when the execution has finished without errors.
Therefore the following elements have been used or changed
The (existing) framework of the “semantic Star IoT” (s*IoT called later) has been used as a basis for a modelling method containing a modelling structure able to execute.
The external programs of this modelling method have been changed to return codes instead of text messages (mostly, not all aspects)
The AdoScript code of the existing elements has been changed. They now catch the return codes of other called scripts (not in every method implemented) and return return codes on their own. This is used to enable an error communication throughout the modelling structure.
Additionally in one element a method has been implemented to call for the element handling the return codes (mentioned in point 5)
Two modelling elements have been introduced: One element does represent the handling of return codes (later called exception handler) and one element represents the connection from any object to the exception handler. The exception handler does call an external program (described in point 6) which returns the messages correlated to the given return code.
An external program has been added. This program does receive the exception code mentioned before from the modelling framework, processes an ontology and returns the messages answering the questions mentioned in the section Use Case
The experiment finished successfully and fulfilled all points mentioned at the beginning of the experiment. It is therefore considered that an implementation of error detecting methods on modelling level is possible.
The source code can be found at : https://gitlab.dke.univie.ac.at/edu-semtech/exception-handling
Results
The exception handling has been implemented. On the one hand the results showed that an implementation based on the model level is possible while maintaining the modelling structure and enhancing the modelling language instead of simply making it more complex. Exceptions can be caught, processed and given back in a readable way to support modellers and users alike.
On the other hand it turned out that a complete and sound implementation of exception handling on the basis of the modelling level is hardly realizable. Exceptions may occur in different code lines because of different reasons. As not all of these reasons can be caught and described the exception handling based on this implementation will always be incomplete and can only meet the most common error scenarios.
These results show that exception handling outside of the model execution framework may enable more informative exception informations but suffers from incompleteness. An other approach combining both methods may be an alternative way: The exceptions are caught by the model execution framework, informations about this exception are given to external programs which then describe the handling and the behaviour of the model execution framework. Such an implementation would be an aim for future researchers to implement structured and error-prune models.