Finish error handling

[syntron]

Finish update of error handling in OMSession.py and ModelicaSystem.py

Based on PR #277, #273 and #270

Changes

• Always check for errors in sendExpression()
• align logging - log data only once
• cleanup

[adeas31]

Rebase this one and see if you can use getMessagesStringInternal(). We should also check if expression is getErrorString() or getMessagesStringInternal() then we should not call it twice.

[syntron]

@adeas31 would it be possible to merge #281 and #282 before that? Both would merge in this order without problems even if not rebased.

This would simplify the merge as this PR is based on these two. Furthermore, I will be limited in time till mid of next week ...

[syntron]

@adeas31 do you have a simple way / an example to force an error? I would like to check how to evaluate the output of getMessagesStringInternal()

[adeas31]

Run the following script with omc,

loadString("model M Real foo = \"str\"; annotation (uses(Modelica(version=\"4.0.0\"))); end M;");
getMessagesStringInternal();
checkModel(M);
getMessagesStringInternal();

equivalent OMPython code is,

from OMPython import OMCSessionZMQ
omc = OMCSessionZMQ()
omc.sendExpression("model M Real foo = \"str\"; annotation (uses(Modelica(version=\"4.0.0\"))); end M;")
omc.sendExpression("getMessagesStringInternal()")
omc.sendExpression("checkModel(M)")
omc.sendExpression("getMessagesStringInternal()")

The first call to getMessagesStringInternal() gives the notificaitons caused by loading model M, the second call gives the error caused by calling checkModel(M).
Note. I haven't tried running the python code but I guess it will work.

You can also see how getMessagesStringInternal() is used in OMEdit here https://github.com/OpenModelica/OpenModelica/blob/master/OMEdit/OMEditLIB/OMC/OMCProxy.cpp#L611

[adeas31]

Let me know once its ready for review.

[syntron]

Let me know once its ready for review.

@adeas31 all done including getMessagesStringInternal() in this PR

Please use the following order for review: PR #281, PR #282 (needs a simple conflict solution), PR #278

PR #279 is currently not updated as it would be on top of PR #278

Besides these, there are some smaller cleanups pending