Со случаем алгоритмических ошибок, видимо, всё ясно... Либо программа работает, либо нет. Должны быть барьеры ошибок на неких уровнях рантайма, которые отвечают за обработку таких отказов и восстановление. Но это вообще внеязыковой вопрос.

Со случаем обработки особых веток событий в системах класса 24*356 ситуация интереснее... Даже если принять полезность try-except, то вот ведь какая штука. Эти средства расчитаны на текущие архитектуры ПО. Так скажем, "промежуточное", застрявшее на середине ООП - это касается всех вариаций, в том числе и КП (я бы даже сказал "шизофреническое" ООП, это ощущается из преподавания - эти механизмы противоестественны, они не идут "от задач"). Суть в том, что мы имеем множество (взаимо)действующих объектов, но при этом они приводятся в движение только одним (или небольшим количеством) потоков выполнения. И эти потоки "шуруют" насквозь через граф из огромного числа обьектов.

Однако естественно ждать перехода к нормальной ситуации, когда "каждый объект сможет поиграть собственным мячом" (С) "Хоттабыч". Собственно, это уже и наблюдается. Параллельное ООП на сообщениях, в котором вместо глубоких вызовов будет активация параллельного исполнителя. Собственно, у швейцарцев в Композите технически такая возможность уже обеспечена - когда вместо вызова процедуры в большинстве случаев идёт активация исполнителя (до миллионов...). До этого таким мог похвастаться Эрланг, но там таки не предлагалось такого упора на замену вспомогательных алгоритмов на параллельных исполнителей.

Так вот, если уж обсуждать проблему обработки особых ситуаций - то имеет смысл уже держать в уме такую перспективу. Как будем делать там, а?В Эрланге вот принцип простой - ошибка в процессе = "моментом в море"HALT, но, естественно, без раскрутки стека, на котором просто раскручивать нечего и не к кому...