Uncought Exceptions in IOptimizers get lost

[pfleck]

Because the Task of IOptimizer.StartAsync() is not awaited in IOptimizerView.startButton_Click any exception that was not yet handled is lost.

This issue applies to the following

• IOptimizerView.startButton_Click: Content.StartAsync();
• CrossValidation.Start: clonedAlgorithm.StartAsync(cancellationToken);
• CrossValidationView.startButton_Click: Content.StartAsync();
• OKBAlgorithmView.startButton_Click: Content.StartAsync();
• OptimizerTask.Start: Item.StartAsync();
• EngineTask:Start: Item.StartAsync();

[jkarder]

r15367:

• the asynchronous calls are now awaited
• added extension method to flatten and handle inner exceptions of AggregateExceptions
• fixed some catch clauses

[pfleck]

reviewed r15367: ok

However, I have two remarks:

In the future, we should address that we currently have some methods that are async but are not named ...Async and do not return a Task (e.g. HL.Clients.Hive.EngineTask.Start). According to Microsoft, the only exception for async void-methods should be eventhandlers ( ​see).

I also think that the explicit catching of any AggregateException (where the new FlattenAndHandle-extension method is used) is not necessary. Previously, when task.Wait was used (e.g. in the Engine), an AggregateException was thrown. Because we now use await, there should not be any AggregateExceptions. If we still want to catch the AggregateException and look for potential OperationCancelledExceptions, I suggest we use a WithoutCancellations Extension like the one presented ​here instead of the FlattenAndHandle. (As discussed with mkommenda, the we will continue catching AggregateExceptions for cases where they are unintentionally thrown or intentionally by using the TPL.)

[abeham]

Looked at the changes, no futher remarks.

[jkarder]

r15384: merged r15367 into stable