OCB interfaces should be checked for null in enter() method #1333
Comments
OK - checking the operation callbacks makes much sense... |
the same applies to the Java Code Generator. The operation callbacks should be checked in the enter method. Init could break existing client code. public void enter() {
|
We could implement it like this:
and define CHECK_UNIMPLEMENTED_VIRTUAL_METHODS in the StatemachineInterface.h file. What's your opinion @terfloth ? |
This wouldn't answer the need expressed at the issue opening. No RTTI being present you cannot use exceptions. If they where there, I would have had an exception on the NULL pointer. I may agree that generating a clean runtime error is better than a NULL pointer exception, but it's still using exceptions. What would fit is a return code to the enter method. It should not break existing code as the function is currently returning a void which is by definition not tested by user code. |
We have to add the checks to ::init() as operation callbacks may be used during variable initialization. Example: operation getSomeValue(): integer
var x : integer = getSomeValue() |
Implemented in Java within the init() function. |
As an example I've implemented defines and changed the return type of the init function into the cpp generator. The first four bits indicates, that an OCB is unimplemented. The four right handed bits indicates, which type of OCB is unimplemented. This can be discussed: The defines in the sc_types.h:
The init function returns three possible errors. They are only generated, if the related interface is used:
|
Great solution ! |
I'm using an embedded environment without any RTTI available, so NULL pointer are not catched. It's quite painfull to have the board stucked in an HW error each time I forgot to map a new OCB interface.
It would be nice to check the interface mapping in the init() or enter() method.
The text was updated successfully, but these errors were encountered: