Wenn man in Workern eine Exception selbst behandeln will, muss man aufpassen, danach auch richtig aufzuräumen. In der UnitOfWork des Work-Items könnten z.B. noch ungespeicherte Datenreste liegen, die beim nächsten Save dann doch den Weg ins Ziel finden oder aber eine erneute Exception auslösen.

Heißt: diese müssen im Allgemeinen vernichtet werden (Rollback). Zusätzlich muss auch der Cache der UOW gelöscht werden, damit ggf. modifizierte XPO-Objekte neu aus der DB geladen werden. Und zuguterletzt müssen neue, ungespeicherte Objekte verworfen werden. Das alles erledigt UnitOfWork.UndoChanges(). Darüber hinaus muss man aber auch aufpassen, nicht etwa selbst noch Referenzen auf möglicherweise veraltete XPO-Objekte zu haben. Diese können notfalls auch per Reload aktualisiert werden.

try
{
    // was immer schief gehen kann
    Save(); // Arbeitsschritt komplett
}
catch (Exception ex) when (!ex.IsThreadAbort())
{
    // UOW aufräumen!
    UnitOfWork.UndoChanges();
    // Fehler protokollieren oder was auch immer
}

Das Aufräumen der UOW verhindert allerdings auch das Speichern eventueller ungespeicherter Änderungen am Work-Item selbst. Wenn da ein Status erhalten bleiben soll, beispielsweise, dass der Arbeitsschritt schon erledigt ist, wenngleich erfolglos, dann muss das nach DropIdentityMap in das Workitem geschrieben und ggf. sofort gespeichert werden.