TaskCanceledException w wyjątku AggregateException nie zawiera śledzenia stosu

Question

Używam zadania Parallel Library do uruchomienia zadania, które po anulowaniu wywołuje wyjątek OperationCanceledException, który jest następnie przechwytywany za pomocą wyjątku AggregateException, w następujący sposób. Wyjątek AggregateException zawiera listę wyjątków TaskCanceledExceptions, które odpowiadają wyrzuconym wyjątkom. Niestety, te wyjątki TaskCanceledException wydają się tracić dane śledzenia stosu generowane przez oryginalne wyjątki. Czy to według projektu?

try 
{ 
    task1.Wait(); 
} 
catch (AggregateException aggEx) 
{ 
    var tcex = ex as TaskCanceledException; 
    if (tcex != null) 
    { 
     Debug.WriteLine("InnerException:{0}, Message:{1}, Source:{2}, StackTrace: {3}", 
      tcex.InnerException, tcex.Message, tcex.Source, tcex.StackTrace); 

     return true; 
    } 
    else 
    { 
     return false; 
    } 
} 

Wynik:

InnerException:, Message:A task was canceled., Source:, StackTrace: 

Answer 1

Myślę, że to przez projekt, zadanie anulowane wyjątki są zazwyczaj tylko wyrzucony, gdy zadanie jest anulowane, jak myśli, aby pomóc zadanie, aby wyjść. Jaki cel ma śledzenie stosu w tej sytuacji? Mając to na uwadze, nie mam wglądu w proces myślenia twórców, którzy zaprojektowali wyjątki od odwołania, tylko moje zdanie.

Nie jestem do końca pewien, co masz na myśli, tracąc ślad stosu rzucony przez oryginalny wyjątek? Zwykle nie mieliby wewnętrznego/oryginalnego wyjątku. Być może anulujesz zadanie z powodu jakiegoś innego wyjątku? W takim przypadku powinieneś przechwytywać "oryginalny" wyjątek w górę strumienia, rejestrować go tam, a następnie anulować po nim.