Zgłaszanie wielu wyjątków w .Net/C#

Question

W aplikacji, nad którą pracuję, każdy błąd logiki biznesowej powoduje zgłoszenie wyjątku, a kod wywołujący obsługuje wyjątek. Ten wzór jest używany w całej aplikacji i działa dobrze.

Mam sytuację, w której będę próbował wykonać szereg zadań biznesowych z poziomu warstwy biznesowej. Wymaganie to polega na tym, że awaria jednego zadania nie powinna spowodować zakończenia procesu. Inne zadania powinny nadal być możliwe do wykonania. Innymi słowy, nie jest to operacja atomowa. Problem polega na tym, że pod koniec operacji chcę powiadomić kod wywołujący, że wystąpił wyjątek lub wyjątki, zgłaszając wyjątek. Rozważmy następujący psuedo-fragment kodu:

function DoTasks(MyTask[] taskList) 
{ 
    foreach(MyTask task in taskList) 
    { 
    try 
    { 
     DoTask(task); 
    } 
    catch(Exception ex) 
    { 
     log.add(ex); 
    } 
    } 

    //I want to throw something here if any exception occurred 
} 

Co mam rzucać? Napotkałem ten wzorzec już w mojej karierze. W przeszłości zachowałem listę wszystkich wyjątków, a następnie wyrzucono wyjątek zawierający wszystkie złapane wyjątki. To nie wydaje się być najbardziej eleganckim podejściem. Ważne jest zachowanie jak największej liczby szczegółów od każdego wyjątku do chwili obecnej do kodu wywołującego.

Myśli?

---

Edytuj: Rozwiązanie musi być napisane w .Net 3.5. Nie mogę korzystać z żadnych bibliotek beta, lub wyjątek AggregateException w .Net 4.0, o którym wspomniała Bradley Grainger (poniżej) byłby dobrym rozwiązaniem dla wyjątków kolekcji do rzucania.

Answer 1

Task Parallel Library extensions NET (która will become part of .NET 4.0) follow wzór proponowanych w innych odpowiedzi: zbierając wszystkie wyjątki, które zostały wyrzucone w klasie AggregateException.

Przez zawsze rzucanie tego samego typu (niezależnie od tego, czy istnieje wyjątek od pracy podrzędnej, czy wielu), kod wywołujący wyjątek jest łatwiejszy do napisania.

W CTP .NET 4.0, AggregateException ma publiczny konstruktor (który zajmuje IEnumerable<Exception>); może to być dobry wybór dla twojej aplikacji.

Jeśli kierujesz aplikację .NET 3.5, rozważ sklonowanie części klasy System.Threading.AggregateException, które potrzebujesz w swoim własnym kodzie, np. Niektórych konstruktorach i właściwości InnerExceptions. (Możesz umieścić swój klon w przestrzeni nazw System.Threading w swoim zespole, co może spowodować zamieszanie, jeśli ujawnisz go publicznie, ale później sprawi, że uaktualnienie do wersji 4.0 będzie łatwiejsze.) Po zwolnieniu .NET 4.0 powinieneś być w stanie "uaktualnić" do typu Framework poprzez usunięcie pliku źródłowego zawierającego twój klon z twojego projektu, zmianę projektu na docelową nową wersję struktury i przebudowanie. Oczywiście, jeśli to zrobisz, musisz uważnie śledzić zmiany w tej klasie, ponieważ Microsoft wypuszcza nowe CTPs, aby twój kod nie stał się niekompatybilny. (Na przykład wygląda to na użyteczną klasę ogólnego zastosowania i można ją przenieść z System.Threading do System.) W najgorszym przypadku można zmienić nazwę typu i przenieść ją z powrotem do własnej przestrzeni nazw (to bardzo proste z większość narzędzi do refaktoryzacji).

Answer 2

No super eleganckie rozwiązanie tutaj jednak kilka pomysłów:

• przekazać funkcję błędu uchwytu jako argument do DoTasks więc użytkownik może zdecydować, czy kontynuować
• zastosować śledzenie do dziennika błędów, które występują
• złączyć wiadomości od innych wyjątków w komunikacie wiązki wyjątkiem jest

Answer 3

Możesz chcieć użyć BackgroundWorker to zrobić dla ciebie. Automatycznie przechwytuje i przedstawia wszelkie wyjątki po zakończeniu, które można następnie wyrzucić lub zaloguj się lub zrobić z czymkolwiek. Otrzymujesz także korzyści wynikające z wielowątkowości.

BackgroundWorker jest ładny otoki wokół delegata asynchronous programming model.

Answer 4

Można utworzyć własny wyjątek, który sam posiada kolekcję wyjątki. Następnie, w swoim bloku Catch, po prostu dodaj go do tej kolekcji. Po zakończeniu procesu sprawdź, czy liczba wyjątków jest> 0, a następnie wyrzuć niestandardowy wyjątek.

Answer 5

Dwa sposoby na górze mojej głowie będzie albo dokonać niestandardowy wyjątek i dodać wyjątki do tej klasy i rzucać że koniec:

public class TaskExceptionList : Exception 
{ 
    public List<Exception> TaskExceptions { get; set; } 
    public TaskExceptionList() 
    { 
     TaskExceptions = new List<Exception>(); 
    } 
} 

    public void DoTasks(MyTask[] taskList) 
    { 
     TaskExceptionList log = new TaskExceptionList(); 
     foreach (MyTask task in taskList) 
     { 
      try 
      { 
       DoTask(task); 
      } 
      catch (Exception ex) 
      { 
       log.TaskExceptions.Add(ex); 
      } 
     } 

     if (log.TaskExceptions.Count > 0) 
     { 
      throw log; 
     } 
    } 

lub return true lub false, jeśli zadania nie powiodło się i mieć zmienna "Out List".

public bool TryDoTasks(MyTask[] taskList, out List<Exception> exceptions) 
    { 
     exceptions = new List<Exception>(); 
     foreach (MyTask task in taskList) 
     { 
      try 
      { 
       DoTask(task); 
      } 
      catch (Exception ex) 
      { 
       exceptions.Add(ex); 
      } 
     } 

     if (exceptions.Count > 0) 
     { 
      return false; 
     } 
     else 
     { 
      exceptions = null; 
      return true; 
     } 
    }