Unhandled Exceptions on the Optimizer's ui-thread causes HL to crash

[pfleck]

Unhandled exception within the Optimizer's ui-thread (e.g. any event handler) should not crash HL, instead the exception should be displayed with ErrorHandling.ShowErrorDialog(...). Currently, however, showing the ErrorDialog can cause yet another Exception, leading to an immediate crash of HL.

There are two facts that lead to this:

• Any unhandled exception in the Optimizer's ui-thread bubbles back to the Application.Run(mainForm);-call in the Optimizer.Plugin.Run method, and the exception is finally caught in StarterForm.StartApplication. There, the exception is forwarded to the ErrorHandling.ShowDialog to present it to the user.
• The used overload of ErrorHandling.ShowErrorDialog(...) tries to display the error dialog on the ui-thread of the StarterForm (not the Optimizer's ui-thread). However, the StarterForm and its ui-thread is usually disposed earlier when the user closes the StarterForm explicitly or when the /hideStarter argument is used. As a result, the ErrorHandling tries to use the disposed StarterForm as owner of the dialog, causing an uncaught ObjectDisposedException and the immediate crash of HL.

A simple fix might be wrapping the Application.Run(mainForm) call in the Optimizer.Plugin.Run inside a try-catch and display the exceptions on the Optimizer's ui-thread. However, this should also be done for all other HLApplications.

Another option would be to keep the StarterForm (and its ui-thread) alive, by only hiding the StarterForm. This way, any exception occurring in any Application could be handled by the ErrorHandling using the StarterForm's ui-thread.

One additional remark: Of course, this only helps with uncaught exception on any ui-thread. Having an uncaught exception on any self-spawned thread will immediately terminate the application (standard behavior of the runtime). Instead, we could move from threads to Tasks, since they don't terminate the whole application if an exception stays uncaught.