Возврат ошибки и дальше работать? Если к примеру прил. шлет логи по сетке в syslog сервер, то при простом возврате ошибки и продолжении работы в таком случае мы можем вовсе положить логсервер.
> А что делать приложению, например, если место на диске кончилось? в Rust — ничего не делать, ведь единственный верный язык не позволяет проверить ошибку при закрытии файла в Go — хендлить ошибку и логировать
В документации четко прописано, что std::fs::File по умолчанию реализует типаж Drop, метод drop() которого автоматически закрывает (пытается) файл. Тут надо не наводить истерику и кричать на весь мир, как мне не нравится язык X, а вдумчиво почитать доку.
если я правильно понял вопрос то такие ошибки ты в любом случае не отловишь и приложение кильнется, вопрос только почему оно кильнется если у тебя приложение накидает логов то необходима правильно рассчитанная ротация логов, и в крупных компаниях обычно есть сборщик логов типа ELK, Splunk, GrayLog, и проблема переполнения из-за логов отпадает
Оно же не кильнется
Плюс сейчас все переходит на контейнеризацию где решатся вопросы выделения ресурсов и автоподнятия
Кильнутся может без проблем, вопрос как код написан
никто не наводит истерику и не кричит, кроме разве что некоторых растоманов но то что в расте намного чаще игнорируются ошибки, чем в Go — факт и причина этому — дизайн обработки ошибок
Меня вот напрягает в го, проверить есть ли ошибка и бросить ее наверх. В 99 я ничего сделать уже не могу, но каждый раз вынужден писать эту проверку - обезьяний труд.
Так не просто бросить на верх а и завернуть в осмыснную ошибку.
Она уже осмысленная... Там парсинг json. Ну свалилось на каком то поле...
Но у вас парсинга ошибка может случиться в разных местах.
я боюсь представить, что вы пишете, если большую часть времени занимает if err != nil
Ну половина кода почти такая. Где-то больше, где-то меньше.
В go продвигается идея о том, что ошибки это часть кода. Когда нужно обработать каждый err, оно легче получается и писать и тестировать.
Обсуждают сегодня