Сообщение Re[2]: Какие у исключений проблемы? от 04.11.2014 20:37
Изменено 04.11.2014 20:37 vsb
Здравствуйте, AlexRK, Вы писали:
vsb>>Какие есть серьёзные аргументы против исключений и за (извиняюсь за каламбур) возврат к кодам возврата? Ведь это же ужасный код, когда после вызова каждой функции мы тут же проверяем err и если он не null, просто передаём его наверх. Это то, от чего избавляют исключения.
ARK>Главная проблема в том, что исключения создают дополнительный скрытый поток управления, который никак в коде не виден.
ARK>Это не было бы проблемой, если бы гарантировалась атомарность всех изменений на некотором участке, на котором предположительно может вылететь исключение. То есть, если исключения нет — коммит, если есть — роллбек. При таком раскладе программа всегда остается в валидном состоянии и все инварианты сохраняются в любой момент времени. Увы, у STM есть фундаментальная проблема — ввод-вывод (на данный момент приемлемого решения этой проблемы не найдено).
ARK>Таким образом, исключения предлагают избавление от лапши проверок, давая взамен потенциально некорректное состояние программы.
ARK>Коды возврата гарантируют видимость всех путей исполнения и отсутствие неожиданных нарушений инвариантов, но генерируют много бойлерплейта.
ARK>Что лучше — хрен знает.
По-моему невалидное состояние после исключения это достаточно редкая штука. Можете привести какие то часто встречающиеся случаи таких состояний? Я только искусственные примеры могу придумать, в реальности я такого не видел (может не замечал).
vsb>>Какие есть серьёзные аргументы против исключений и за (извиняюсь за каламбур) возврат к кодам возврата? Ведь это же ужасный код, когда после вызова каждой функции мы тут же проверяем err и если он не null, просто передаём его наверх. Это то, от чего избавляют исключения.
ARK>Главная проблема в том, что исключения создают дополнительный скрытый поток управления, который никак в коде не виден.
ARK>Это не было бы проблемой, если бы гарантировалась атомарность всех изменений на некотором участке, на котором предположительно может вылететь исключение. То есть, если исключения нет — коммит, если есть — роллбек. При таком раскладе программа всегда остается в валидном состоянии и все инварианты сохраняются в любой момент времени. Увы, у STM есть фундаментальная проблема — ввод-вывод (на данный момент приемлемого решения этой проблемы не найдено).
ARK>Таким образом, исключения предлагают избавление от лапши проверок, давая взамен потенциально некорректное состояние программы.
ARK>Коды возврата гарантируют видимость всех путей исполнения и отсутствие неожиданных нарушений инвариантов, но генерируют много бойлерплейта.
ARK>Что лучше — хрен знает.
По-моему невалидное состояние после исключения это достаточно редкая штука. Можете привести какие то часто встречающиеся случаи таких состояний? Я только искусственные примеры могу придумать, в реальности я такого не видел (может не замечал).
Re[2]: Какие у исключений проблемы?
Здравствуйте, AlexRK, Вы писали:
vsb>>Какие есть серьёзные аргументы против исключений и за (извиняюсь за каламбур) возврат к кодам возврата? Ведь это же ужасный код, когда после вызова каждой функции мы тут же проверяем err и если он не null, просто передаём его наверх. Это то, от чего избавляют исключения.
ARK>Главная проблема в том, что исключения создают дополнительный скрытый поток управления, который никак в коде не виден.
ARK>Это не было бы проблемой, если бы гарантировалась атомарность всех изменений на некотором участке, на котором предположительно может вылететь исключение. То есть, если исключения нет — коммит, если есть — роллбек. При таком раскладе программа всегда остается в валидном состоянии и все инварианты сохраняются в любой момент времени. Увы, у STM есть фундаментальная проблема — ввод-вывод (на данный момент приемлемого решения этой проблемы не найдено).
ARK>Таким образом, исключения предлагают избавление от лапши проверок, давая взамен потенциально некорректное состояние программы.
ARK>Коды возврата гарантируют видимость всех путей исполнения и отсутствие неожиданных нарушений инвариантов, но генерируют много бойлерплейта.
ARK>Что лучше — хрен знает.
По-моему невалидное состояние после исключения это достаточно редкая штука. Можете привести какие то часто встречающиеся случаи таких состояний в managed языке (Java/C# например)? Я только искусственные примеры могу придумать, в реальности я такого не видел (может не замечал).
vsb>>Какие есть серьёзные аргументы против исключений и за (извиняюсь за каламбур) возврат к кодам возврата? Ведь это же ужасный код, когда после вызова каждой функции мы тут же проверяем err и если он не null, просто передаём его наверх. Это то, от чего избавляют исключения.
ARK>Главная проблема в том, что исключения создают дополнительный скрытый поток управления, который никак в коде не виден.
ARK>Это не было бы проблемой, если бы гарантировалась атомарность всех изменений на некотором участке, на котором предположительно может вылететь исключение. То есть, если исключения нет — коммит, если есть — роллбек. При таком раскладе программа всегда остается в валидном состоянии и все инварианты сохраняются в любой момент времени. Увы, у STM есть фундаментальная проблема — ввод-вывод (на данный момент приемлемого решения этой проблемы не найдено).
ARK>Таким образом, исключения предлагают избавление от лапши проверок, давая взамен потенциально некорректное состояние программы.
ARK>Коды возврата гарантируют видимость всех путей исполнения и отсутствие неожиданных нарушений инвариантов, но генерируют много бойлерплейта.
ARK>Что лучше — хрен знает.
По-моему невалидное состояние после исключения это достаточно редкая штука. Можете привести какие то часто встречающиеся случаи таких состояний в managed языке (Java/C# например)? Я только искусственные примеры могу придумать, в реальности я такого не видел (может не замечал).