История изменений
Исправление den73, (текущая версия) :
В общем я понял, что в го и расте ничего нового не придумали. Почти. Попробую сжато изложить всю суть проблемы, а вы поправьте:
1. Ошибки усложняют программу на одно измерение пространства.
2. Нам это не нравится и мы пытаемся избавиться.
3. Наивные способы - всегда падать и всегда игнорировать - в целом негодны. Первый годится для работающего прототипа, второй - для демонстрации перед заказчиком. Но правды в них нет.
4. Не решая всей сложности проблемы ошибок, можно хотя бы локализовать последствия.
Способы:
4.1. Связать ресурсы с процессом, как это делает операционная система. Грохнем процесс, но ОС останется жива.
4.2. Связать ресурсы со стеком (RAII). В этом случае мы можем грохнуть нить или часть стека - живучесть процесса повышается. Здесь возникает проблема того, что освобождение ресурса - это тоже осмысленное действие, требующее, чтобы программа была в порядке. Если возникла серьёзная проблема, может оказаться невозможно освободить ресурс силами процесса. В С++ это проявляется как «исключение в деструкторе», но проблема находится не в языке, а в природе вещей.
5. Если речь идёт о разделении на библиотеку и приложение, то возникает вопрос о сигнатуре библиотеки. Документация заведомо ненадёжна. Надёжны коды возврата и checked исключения. checked исключения не прижились либо из-за многословности, либо потому что они нарушают модульность, а модульность была объявлена догмой. Коды возврата делают программы, по мнению некоторых, слишком многословными. И их можно забыть проверить.
6. Поведение по умолчанию, когда разработчик не обработал ситуацию. Здесь у лиспа преимущество, поскольку он позволяет до раскрутки стека принять решение о том, как поступить. Можно упасть без раскрутки стека, можно с раскруткой, можно запустить отладчик.
7. Авторы Раста предпочли, чтобы программы были статически анализируемыми, пусть и многословными. Поэтому пошли по пути кодов ошибок, постаравшись подсластить его. Кроме того, они сделали так, что нельзя совсем забыть проверить код ошибки (unwrap упадёт, а не проглотит непроверенную ошибку). Но некоторые ситуации настолько страшны и вездесущи, что для них придумали панику. В этом авторы Раста поступили более-менее мудро. Вопрос модульности, который помешал прижиться unchecked исключениям, они не решили. Насчёт исключения в деструкторе я не в теме, но насколько я понял, заморочки с этим там тоже есть.
Дополняйте, если я что-то упустил. Это пока не ответ на мой вопрос, а лишь анализ ситуации.
Исправление den73, :
В общем я понял, что в го и расте ничего нового не придумали. Почти. Попробую сжато изложить всю суть проблемы, а вы поправьте:
1. Ошибки усложняют программу на одно измерение пространства.
2. Нам это не нравится и мы пытаемся избавиться.
3. Наивные способы - всегда падать и всегда игнорировать - в целом негодны. Первый годится для работающего прототипа, второй - для демонстрации перед заказчиком. Но правды в них нет.
4. Не решая всей сложности проблемы ошибок, можно хотя бы локализовать последствия.
Способы:
4.1. Связать ресурсы с процессом, как это делает операционная система. Грохнем процесс, но ОС останется жива.
4.2. Связать ресурсы со стеком (RAII). В этом случае мы можем грохнуть нить или часть стека - живучесть процесса повышается. Здесь возникает проблема того, что освобождение ресурса - это тоже осмысленное действие, требующее, чтобы программа была в порядке. Если возникла серьёзная проблема, может оказаться невозможно освободить ресурс силами процесса. В С++ это проявляется как «исключение в деструкторе», но проблема находится не в языке, а в природе вещей.
5. Если речь идёт о разделении на библиотеку и приложение, то возникает вопрос о сигнатуре библиотеки. Документация заведомо ненадёжна. Надёжны коды возврата и checked исключения. checked исключения не прижились либо из-за многословности, либо потому что они нарушают модульность, а модульность была объявлена догмой. Коды возврата делают программы, по мнению некоторых, слишком многословными. И их можно забыть проверить.
6. Поведение по умолчанию, когда разработчик не обработал ситуацию. Здесь у лиспа преимущество, поскольку он позволяет до раскрутки стека принять решение о том, как поступить. Можно упасть без раскрутки стека, можно с раскруткой, можно запустить отладчик.
7. Авторы Раста предпочли, чтобы программы были статически анализируемыми, пусть и многословными. Поэтому пошли по пути кодов ошибок, постаравшись подсластить его. Кроме того, они сделали так, что нельзя совсем забыть проверить код ошибки (unwrap упадёт, а не проглотит непроверенную ошибку). Но некоторые ситуации настолько страшны и вездесущи, что для них придумали панику. В этом авторы Раста поступили более-менее мудро. Вопрос модульности, который помешал прижиться unchecked исключениям, они не решили. Насчёт исключения в деструкторе я не в теме.
Дополняйте, если я что-то упустил. Это пока не ответ на мой вопрос, а лишь анализ ситуации.
Исправление den73, :
В общем я понял, что в го и расте ничего нового не придумали. Почти. Попробую сжато изложить всю суть проблемы, а вы поправьте:
1. Ошибки усложняют программу на одно измерение пространства.
2. Нам это не нравится и мы пытаемся избавиться.
3. Наивные способы - всегда падать и всегда игнорировать - в целом негодны. Первый годится для работающего прототипа, второй - для демонстрации перед заказчиком. Но правды в них нет.
4. Не решая всей сложности проблемы ошибок, можно хотя бы локализовать последствия.
Способы:
4.1. Связать ресурсы с процессом, как это делает операционная система. Грохнем процесс, но ОС останется жива.
4.2. Связать ресурсы со стеком (RAII). В этом случае мы можем грохнуть нить или часть стека - живучесть процесса повышается. Здесь возникает проблема того, что освобождение ресурса - это тоже осмысленное действие, требующее, чтобы программа была в порядке. Если возникла серьёзная проблема, может оказаться невозможно освободить ресурс силами процесса. В С++ это проявляется как «исключение в деструкторе», но проблема находится не в языке, а в природе вещей.
5. Если речь идёт о разделении на библиотеку и приложение, то возникает вопрос о сигнатуре библиотеки. Документация заведомо ненадёжна. Надёжны коды возврата и checked исключения. checked исключения не прижились либо из-за многословности, либо потому что они нарушают модульность, а модульность была объявлена догмой. Коды возврата делают программы, по мнению некоторых, слишком многословными. И их можно забыть проверить.
6. Поведение по умолчанию, когда разработчик не обработал ситуацию. Здесь у лиспа преимущество, поскольку он позволяет до раскрутки стека принять решение о том, как поступить. Можно упасть без раскрутки стека, можно с раскруткой, можно запустить отладчик.
7. Авторы Раста предпочли, чтобы программы были статически анализируемыми, пусть и многословными. Поэтому пошли по пути кодов ошибок, постаравшись подсластить его. Кроме того, они сделали так, что нельзя совсем забыть проверить код ошибки (unwrap упадёт, а не проглотит непроверенную ошибку). Но некоторые ситуации настолько страшны и вездесущи, что для них придумали панику. В этом авторы Раста поступили более-менее мудро. Вопрос модульности, который помешал прижиться unchecked исключениям, они не решили.
Дополняйте, если я что-то упустил. Это пока не ответ на мой вопрос, а лишь анализ ситуации.
Исходная версия den73, :
В общем я понял, что в го и расте ничего нового не придумали. Почти. Попробую сжато изложить всю суть проблемы, а вы поправьте:
1. Ошибки усложняют программу на одно измерение пространства. 2. Нам это не нравится и мы пытаемся избавиться.
3. Наивные способы - всегда падать и всегда игнорировать - в целом негодны. Первый годится для работающего прототипа, второй - для демонстрации перед заказчиком. Но правды в них нет.
4. Не решая всей сложности проблемы ошибок, можно хотя бы локализовать последствия.
Способы:
4.1. Связать ресурсы с процессом, как это делает операционная система. Грохнем процесс, но ОС останется жива.
4.2. Связать ресурсы со стеком (RAII). В этом случае мы можем грохнуть нить или часть стека - живучесть процесса повышается. Здесь возникает проблема того, что освобождение ресурса - это тоже осмысленное действие, требующее, чтобы программа была в порядке. Если возникла серьёзная проблема, может оказаться невозможно освободить ресурс силами процесса. В С++ это проявляется как «исключение в деструкторе», но проблема находится не в языке, а в природе вещей.
5. Если речь идёт о разделении на библиотеку и приложение, то возникает вопрос о сигнатуре библиотеки. Документация заведомо ненадёжна. Надёжны коды возврата и checked исключения. checked исключения не прижились либо из-за многословности, либо потому что они нарушают модульность, а модульность была объявлена догмой. Коды возврата делают программы, по мнению некоторых, слишком многословными. И их можно забыть проверить.
6. Поведение по умолчанию, когда разработчик не обработал ситуацию. Здесь у лиспа преимущество, поскольку он позволяет до раскрутки стека принять решение о том, как поступить. Можно упасть без раскрутки стека, можно с раскруткой, можно запустить отладчик.
7. Авторы Раста предпочли, чтобы программы были статически анализируемыми, пусть и многословными. Поэтому пошли по пути кодов ошибок, постаравшись подсластить его. Кроме того, они сделали так, что нельзя совсем забыть проверить код ошибки (unwrap упадёт, а не проглотит непроверенную ошибку). Но некоторые ситуации настолько страшны и вездесущи, что для них придумали панику. В этом авторы Раста поступили более-менее мудро. Вопрос модульности, который помешал прижиться unchecked исключениям, они не решили.
Дополняйте, если я что-то упустил. Это пока не ответ на мой вопрос, а лишь анализ ситуации.