Free cookie consent management tool by TermsFeed Policy Generator

Opened 7 years ago

Closed 7 years ago

#2830 closed defect (done)

Uncought Exceptions in IOptimizers get lost

Reported by: pfleck Owned by: jkarder
Priority: medium Milestone: HeuristicLab 3.3.15
Component: Optimization.Views Version: trunk
Keywords: Cc:

Description (last modified by 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();

Change History (8)

comment:1 Changed 7 years ago by pfleck

  • Owner set to pfleck
  • Status changed from new to accepted

comment:2 Changed 7 years ago by pfleck

  • Description modified (diff)

comment:3 Changed 7 years ago by jkarder

  • Owner changed from pfleck to jkarder
  • Status changed from accepted to assigned

comment:4 Changed 7 years ago by jkarder

  • Status changed from assigned to accepted

comment:5 Changed 7 years ago by jkarder

  • Owner changed from jkarder to pfleck
  • Status changed from accepted to reviewing
  • Version changed from 3.3.14 to trunk


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

comment:6 Changed 7 years ago by pfleck

  • Owner changed from pfleck to abeham

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.)

comment:7 Changed 7 years ago by abeham

  • Owner changed from abeham to jkarder
  • Status changed from reviewing to readytorelease

Looked at the changes, no futher remarks.

comment:8 Changed 7 years ago by jkarder

  • Resolution set to done
  • Status changed from readytorelease to closed

r15384: merged r15367 into stable

Note: See TracTickets for help on using tickets.