> -- Galkov писал(а):
> Правильно ли я понял, что вместо того, чтобы не писать НИЧЕГО при обработке мат.операторов (в т.ч. и просто сложение), Вы отключали прерывания FPU, а после выполнения вычислительной операции - проверяли флаги (не будем уточнять какие) сопроцессора
Есть два пути. Первый - компилировать программу с отключёнными исключениями при FPU-ошибках. Тогда нужно проверять результат на NaN, +-Infinity. Во втором случае использовать исключения. Их можно и нужно использовать в коде, который содержит атомарную операцию и не содержит искусственного вызова исключений (raise), если блок охраны идёт сразу за атомарной операцией.

## Код:
```
TRY a+b EXCEPT MyCode END = IF NOT System.SafeSum(a, b) THEN Mycode END;
```


Мы уже обсуждали это с Владом. Можно написать эти самые SafeSum/Div/Mul, можно использовать исключения. Структурность не ломается. Запись оригинальная, просто, в силу ограничений имеющегося интрументария. Также ничего страшного нет в том, чтобы ловить исключения отдельных потоков, при условии, что они после этого будут тихо убиты и что они сама RAISE не вызывают.

Ошибку можно передавать и через переменную потока, а функции возвращать будут только её признак (boolean);

## Код:
```
SetError(TMyError.Create(...));
RESULT:=FALSE;
...
PROCEDURE SetError (ErrObj: TErrorObj);
BEGIN
  FreeAndNIL(Error);
  Error:=ErrObj;
END;
```

Фактически, мы ликвидировали таким образом сложность кодов возврата (их просто нет, есть флаг ошибки). А вот продумать иерархию классов ошибок всё равно нужно, как и поля объектов ошибок. То бишь сложность в целом не убралась, разве что частично, так как теперь ошибки - целые структуры. То же самое делает и RAISE TMyError, только ломая блоки и тем самым подрывая весь смысл классического структурного программирования.