Исключение "обрабатывается", если метод, который его перехватил, может удовлетворить свою конструкцию. Например, контракт для подпрограммы OpenRecentDocument, которая вызывается, когда пользователь выбирает элемент в меню «последние файлы», может указывать, что он должен (1) успешно открыть окно документа или (2) безуспешно попытаться открыть окно документа, откатить любые побочные эффекты, возникающие в результате попытки, и уведомить пользователя о том, что произошло. Если OpenRecentDocument ловит исключение при попытке открыть файл, но может откатить любые побочные эффекты от попытки и уведомить пользователя, подпрограмма выполнит свой контракт и, следовательно, должна вернуться без повторного выброса исключения.
Одна неприятная «ошибка» во всем этом заключается в том, что не существует каких-либо стандартных средств, с помощью которых подпрограммы, которые выдают исключение, могут указывать, привела ли их попытка к выполнению побочных эффектов, которые нельзя было откатить. Не существует неотъемлемого способа, например, отличить InvalidOperationException, который неожиданно возникает при обновлении общей структуры данных (что может означать, что другие открытые документы могли быть повреждены), от InvalidOperationException, который возникает при обновлении связанных данных с загружаемым документом, даже если кто-то предвидел последнюю возможность и предоставил ее. Лучшее, что можно сделать, это либо попытаться поймать любой InvalidOperationException, который может произойти в последней ситуации рядом с местом, где это происходит, инкапсулировать это исключение в некоторый другой тип исключения и выбросить его, либо структуры данных поддерживают объект " «поврежден» и убедитесь, что, если структура данных будет повреждена, все будущие операции с ней будут проходить как можно более чисто. Ни один из подходов не является элегантным. Более распространенный подход, который, вероятно, можно охарактеризовать как «надежда на лучшее», обычно работает.