Парадигма обработки исключений в C ++, которая образует частичную основу для Java, и, в свою очередь, .net, вводит некоторые хорошие концепции, но также имеет некоторые серьезные ограничения. Одна из ключевых целей разработки обработки исключений - позволить методам гарантировать, что они будут либо удовлетворять свои постусловия, либо выдавать исключение, а также гарантировать, что произойдет любая очистка, которая должна произойти до выхода из метода. К сожалению, парадигмы обработки исключений в C ++, Java и .net не могут обеспечить каких-либо хороших средств для обработки ситуации, когда непредвиденные факторы препятствуют выполнению ожидаемой очистки. Это, в свою очередь, означает, что нужно либо рискнуть, когда все остановится, если произойдет что-то неожиданное (подход C ++ к обработке исключения во время разматывания стека), принять возможность того, что условие не может быть решено из-за возникшей проблемы во время очистки стека будет принят за ошибку, которую можно решить (и могло бы случиться, если бы очистка прошла успешно), или допустим, что неразрешимая проблема, чья очистка стека вызывает очистку, вызывает исключение, которое обычно разрешается, незамеченным, поскольку код, который обрабатывает последнюю проблему, объявляет ее «решенной».
Даже если обработка исключений, как правило, была бы хорошей, необоснованно считать неприемлемой парадигму обработки исключений, которая не обеспечивает хорошее средство для обработки проблем, возникающих при очистке после других проблем. Это не означает, что фреймворк не может быть спроектирован с парадигмой обработки исключений, которая могла бы обеспечить разумное поведение даже в сценариях с множественными сбоями, но ни один из лучших языков или фреймворков пока не может этого сделать.