Здравствуйте, νsb, Вы писали:
νsb>При компиляции можно ставить опцию, когда паника сразу грохает приложение. Поэтому для библиотек панику вместо возврата ошибок делать нельзя. νsb>Для своих приложений в теории — можно. Это действительно очень похоже на исключения. Но это будет как с go, вся стандартная библиотека и все сторонние библиотеки используют другой механизм обработки ошибок, поэтому тут или всё переписывать/оборачивать, или будет в проекте две системы обработки ошибок. νsb>В целом лучше писать код так, как пишут другие.
Ты конечно же всё верно написал, но я всё же добавлю концептуальное насчёт разных механизмов обработки ошибок в приложение.
В любом приложение обязательно должно быть два отдельных способа: обработки ошибок и обработки исключительных ситуаций. Это принципиально разные ситуации с разной необходимой реакций и с разными удобными способами реализации. В первом случае (например при попытке открытия заблокированного файла) приложение должно уведомить (обычно через GUI) пользователя о проблеме и спокойно продолжить выполнение. В этом случае очевидно необходима обработка по месту (часто прямо в той же функции, где открываем файл), поэтому штуки типа классических исключений здесь максимально неудобны (из-за необходимости обкладывать каждый вызов в try/catch). А вот во втором случае (исключительных ситуаций, типа нехватки памяти на машине) приложение обычно просто завершает свою работу, возможно записав что-то в лог (или отправив отчёт на сервер). И здесь наоборот максимально удобен подход с исключениями, в виде одного глобального обработчика на приложение или поток.
Всё вышеописанное касается приложений написанных на любых языках. Но в большинстве языков есть один встроенный механизм обработки, который разработчики из-за незнания/неумения/безысходности используют для всех ситуаций. От этого и возникают все подобные неоднозначности и холивары.
Rust же здесь выгодного отличается наличием двух отдельных механизмов, каждый под свою ситуацию. Паники для обработки исключительных ситуаций и Result для обычных ошибок.
