S>Что такое глобальная переменная в контексте записи на диск? Содержимое жестокого диска + (опционально)RAM?
Речь о детерминизме: если содержимое диска (и RAM) детерминировано (т.е. мы _ЗНАЕМ_, что читаем таблицу умножения с диска, или знаем, что мы читаем ровно тот же файл, что и будет там дальше), смысла добавлять это в метаданные пролетающего исключения нет. Попробую еще раз повторить: перехватывать и модифицировать исключение нужно только в тех случаях, когда поведение функции проблематично из-за отсутствия повторяемости (детерминизма).
В контексте тестирования: зачем мы используем моки? Да ровно затем, чтобы поведение SUT (system under test) было детерминированным. Иначе вместо отладки своей системы мы будем отлаживать баги зависимостей.
Кстати, о метаданных. В контексте все того же pread, возвращающего ENOENT — сдается мне, редко когда в пролетающее исключение будут добавлять, например, половину прочитанных данных (потому что ошибка произошла при чтении второй половины).
S>компьютеров? И как предполагается взаимодействовать, если нету глобальных переменных?
Очевидно же, что целью запуска программ как раз являются какие-то побочные эффекты (например, вывод чего-то на экран). Но код, где эти эффекты создаются, при грамотном проектировании всегда хорошо локализован. К примеру, слой, который пишет данные на диск, обычно отделен от вычислительного слоя. Именно затем и отделен, чтбоы минимизировать те самые побочные эффекты. Чтобы можно было легко и надежно тестировать. Я не знаю, сколько раз уже говорили о том, что раскидывать state changes по всему коду так себе идея. Сколько уже этих разговоров про transactional behaviour (а ведь это не что иное как выделение побочных эффектов в две специальные области, read и write, так что первое осуществляется при старте транзакции, второе — при commit'е).
S>О каких инструментах речь? А почему именно инструменты, а не методологии?
Методологию я тоже считаю инструментом. Кроме методологии, могут быть и непосредственно технические решения (да те же транзакции), и языки (более-менее припоминается Haskell, ибо вышеупомянутый erlang ну очень прагматичен в этих вопросах, и не пытается ограничить создание побочных эффектов).
