Exception handling

[modelica-tools]

Exception handling

[modelica-trac-importer]

Comment by iakovn on 17 Dec 2012 21:48 UTC
I don’t see any proper use case for this feature. FMU that raises such exceptions should be run under a debugger to track error sources. The generated log from the checker will give a good indication where the error might be.
On the technical side: exceptions are not propagated via DLL interface. Catching those as signals may interfere with internal exception handling in the FMU and will actually complicate debugging. A way around may be to load FMU in a separate process but that would also make proper debugging more cumbersome.
I’d put resolution as “will not fixed”

[modelica-trac-importer]

Comment by anonymous on 18 Dec 2012 12:19 UTC
I suppose a clean program termination would always be professional. That's why I suggested it. But you are right it is not needed at all as FMU Checker runs on one FMU only and not on a whole bunch of them to check in series. Thus you can keep it crashing and I do the debugging.

[modelica-trac-importer]

Comment by jakesson on 18 Dec 2012 13:34 UTC
Replying to [comment:2 anonymous]:

I suppose a clean program termination would always be professional. That's why I suggested it. But you are right it is not needed at all as FMU Checker runs on one FMU only and not on a whole bunch of them to check in series. Thus you can keep it crashing and I do the debugging.

The ambition of the checker is certainly that it should be a professional tool useful for FMU-generator implementors. As I understand your response, you are not content with the reply Iakovs post. There were technical arguments brought forward by Iakov against the original feature request in this ticket - I therefore kindly ask you to comment upon these if there are still concerns.

[modelica-trac-importer]

Comment by anonymous on 18 Dec 2012 16:25 UTC
Sorry, there should not be any offense here.

Actually, what I did, is to use log level 6 to see where it crashed, then noticed that it is inside one of our DLLs required for the FMU DLL, then compiled that one with debug information and then found the reason for the crash.

I mean this way is always possible. However, if you see FMU Checker crashing, you never know if it is the FMU Checker itself or one of the loaded DLLs that leads to the crash. First sight is likely to be: Damn, FMU Checker always crashes. If there would be some indication that it is not FMU Checker having the access violation would be not only more professional but also keeps a good light on the tool.

From technical point of view: I know tools that do the exception handling like I suggested above. The above examples actually came from popluar file manager Total Commander that can load external plugins but certainly should not crash if the plugin fails. At least there is an exception message that the error is within the plugin. Always good to know.

Anyway, it is just a nice-to-have wish and it is technically possible.

[modelica-trac-importer]

Comment by iakovn on 18 Dec 2012 22:42 UTC
Replying to [comment:2 anonymous]:

But you are right it is not needed at all as FMU Checker runs on one FMU only and not on a whole bunch of them to check in series.

Actually, it does work with a bunch when coupled with ctest. If you build the checker yourself then you could set FMUCHK_TEST_FMUS_DIR to a directory with your FMUs. Running "make test" or building RUN_TESTS target in VisualStudio will run the checker on all the FMUs.

Thus you can keep it crashing and I do the debugging.

The whole point is that it should not crash. It needs to be debugged if it does. If its checker's fault - report the bug and we fix it ASAP.

I know tools that do the exception handling like I suggested above.

The only safe way is to load the FMU binary in a separate process. This will make checker slower which is undesirable. Performance is specifically important if you run it in a batch on many FMUs (e.g., as mentioned above).

We'll keep this on the wish list but not as critical.

[modelica-trac-importer]

Comment by jakesson on 19 Dec 2012 08:09 UTC
I think that both approaches have merits. I can certainly see the value of catching FMU exceptions in a clean way without the checker crashing. In this way, the user gets guidance in debugging inside the FMU, and we avoid uncertainty about weather the error is in the checker and in the FMU. On the other, hand, if catching exceptions complicates debugging, then it would be good to be able to run without this feature.

Perhaps the following approach would combine the two aspects:

1. By default, the checker catches exceptions from the FMU and report them in a clean way. To the extent there is a performance penalty associated with this, it should be acceptable when the checker is run from the command line. The printed message should make a reference to the mode of operation described in 2. below.
2. There is an argument to turn the catching of exceptions off, in order to more easily debug FMUs. This may also be the desired mode of operation for batch runs.

Since the conclusion so far is that this is not critically needed, we'll put it on the todo list, still, feel free to comment in order for us to have a good design when we get around to implement it.

[modelica-trac-importer]

Comment by anonymous on 19 Dec 2012 12:04 UTC
Johan, thank you for your conclusion.

I did not know that there is a (hidden?) option to run FMU Checker on a directory and I do not know how it is done. But for this scenario it is a reasonable idea to not crash at one of the FMUs and keeping others not checked.

[modelica-trac-importer]

Comment by iakovn on 8 Jan 2013 22:08 UTC
Replying to [comment:7 anonymous]:

I did not know that there is a (hidden?) option to run FMU Checker on a directory

Sorry, I was not clear in my post.
The option is for the checker's build system and not for the checker executable. It is mentioned in BUILD-FMUChecker.txt.
You can specify a "test FMUs" directory when configuring a build. Running "make test" or building RUN_TESTS target in VisualStudio will run the checker on all the FMUs in this directory. The wrapper program (ctest) will report any unhandled exceptions. TestOutput sub-directory in your build tree will contain output files (logs and csv) for all the cases.

[modelica-trac-importer]

Comment by andreas.junghanns on 12 Nov 2015 12:33 UTC
This is aksing to extend the scope of the checker and is currently not urgent (albeit nice to have).