Jak mogę sprawdzić, czy wyjątek został już zgłoszony?

Question

Pracuję nad automatyzacją testów dla usługi i znalazłem sposób na zwinięcie jakiejś typowej konfiguracji weryfikacji & w klasie "sesji".

koncepcyjnej precedensowe może wyglądać następująco:

using (var managerSession = new Session(managerRole)) 
{ 
    // A manager puts some items in warehouse 
} 

using (var employeeSession = new Session(employeeRole)) 
{ 
    // An employee moves items from warehouse to store 
} 

using (var customerSession = new Session(customerRole)) 
{ 
    // A customer can buy items from the store 
} 

W konstruktorze obiektu Sesja I ustanowienia połączenia z usługą mam testowanie z właściwego uwierzytelniania za rolę etc, aw Zużyty sesji() Metoda Mam wspólny blok sprawdzania poprawności, który na przykład sprawdza, czy nie wystąpiły błędy po stronie serwera lub ostrzeżenia podczas sesji.

Oczywiście, jest to pewnego rodzaju nadużywanie wzorca IDispose, a jeśli kod testowy w blokach przy użyciu zgłasza wyjątek ORAZ blok sprawdzania poprawności również zgłasza wyjątek, drugi wyjątek zamaskuje pierwszy.

koncepcyjnym, jeśli mamy ten scenariusz:

using (var managerSession = new Session(managerRole)) 
{ 
    Assert.IsTrue(managerSession.DoJob(), "Manager did not do his job"); 
} 

... i assert nie powiedzie się lub wywołanie managerSession.DoJob() zgłasza wyjątek, następnie chciałbym metody Session Dispose() do pomiń blok walidacji, czyli

public void Dispose() 
{ 
    if (NoExceptionThrown()) 
    { 
     Assert.IsFalse(this.serviceConnection.HasErrors(), "Service connection has errors"); 
    } 

    this.serviceConnection.Dispose(); 
} 

... taki, że metoda badania nie powiedzie się z „połączenie z usługą zawiera błędy”, jeśli rzeczywiście nie powiedzie się z „Menedżer nie wykonywać swoją pracę”

Moje pytanie brzmi: Czy jest w ogóle możliwe wdrożenie metody "NoExceptionThrown()"? Czy istnieje jakaś globalna właściwość, którą można sprawdzić, lub coś ukrytego w wątku.CurrentThread, które można wykorzystać?

Aktualizacja:

Moje pytanie brzmi nie jak byłaby to :-)

Mógłbym oczywiście użyć tego wzoru Zamiast:

Session.ForRole(managerRole, (session) => { /* Test code here */ }); 

ze statycznym sposobem ForRole() zdefiniowany jako

public static void ForRole(Role r, Action<Session> code) 
{ 
    var session = new Session(r); 
    try 
    { 
     code(session); 
     Assert.IsFalse(session.serviceConnection.HasErrors()); 
    } 
    finally 
    { 
     session.Dispose(); 
    } 
} 

Ciekaw jestem, czy istnieje jakiś sposób na uchwycenie stanu wyjątku, jak opisano powyżej.

Answer 1

Byłoby pomocne, gdyby nie było przeciążenie IDisposable.Dispose która odbyła parametr typu Exception aby wskazać, co jest wyjątkiem, jeśli w ogóle, jest w toku w kontekście finally związanego z jej czyszczenia.Podczas gdy metoda Dispose zasadniczo nie powinna zajmować się szczegółami wyjątku, mogą pojawić się warunki podczas metody, która powinna być zgłaszana do wywołującego. Każdy wyjątek zgłoszony przez Dispose zastąpi każdy wyjątek, który był w toku w kontekście dzwoniącego finally, więc byłoby pomocne, gdyby metoda Dispose mogła enkapsulować oczekujący wyjątek przed jego zastąpieniem. Niestety, taka funkcja nie istnieje i nie oczekuję, że zostaną dodane.

Chociaż istnieje kilka hacków, które mogą zostać użyte do osiągnięcia czegoś podobnego do pożądanego efektu, jedyną semantycznie poprawną metodą jest, aby wyjątek był parametrem metody Dispose. Problem z jakimkolwiek innym podejściem polega na tym, że kod Dispose może być uruchamiany z wielu bloków zagnieżdżonych, z których pewne mają oczekujące wyjątki, a niektóre z nich nie; kod, który bada kontekst wykonania w celu określenia statusu najgłębiej zagnieżdżonego bloku, może się nie udać, jeśli ten blok nie jest tym, który chroni czas życia obiektu, który jest usuwany.

Answer 2

Jednym, pewnym, ale brzydkim sposobem na to jest posiadanie boola (domyślnie false) na twojej klasie.

using (var managerSession = new Session(managerRole)) 
{ 
    Assert.IsTrue(managerSession.DoJob(), "Manager did not do his job"); 
    managerSession.NoExceptionThrown = true; 
} 

Nie wydaje mi się, że dzięki swojemu IDisposable będziecie robić o wiele czystsze.

W tym przypadku spróbuj ... catch ... w końcu może działać lepiej, ponieważ masz bezpośredni dostęp do obiektu wyjątku, który możesz przetestować pod kątem null-ness (czy to słowo?) I ewentualnie przechowuj go nawet do późniejszego wykorzystania. Nie powinieneś niczego tracić, ponieważ using jest po prostu cukrem, by wreszcie spróbować złapać.