Здравствуйте, alex_public, Вы писали:
_>>>Ну, то что ты описал — это как раз случай не исключительной ситуации, а обычной обработки ошибок и соответственно удобнее это обрабатывать не исключениями, а через Result. vsb>>Нет, удобней это обрабатывать именно исключениями. Т.к. при этом мне не нужно писать никакого кода.
_>Твоя фраза подразумевает, что при обработке с исключениями не надо писать какой-то код, который надо писать при обработке ошибок через Result в Rust'e. И т.к. это очевидно не код самой реакции на ошибку (который естественно надо писать в любом подходе и языке), то тогда о чём собственно речь? Или ты считаешь "дополнительным кодом" несколько знаков вопроса?
Ну смотри. Может я в расте что-то не понимаю.
Во-первых у каждой функции с ошибками надо возвращать Result вместо конкретного типа. Это как минимум синтаксический шум.
Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик. Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
В-третьих — да, вопрос это дополнительный код с не такой уж и тривиальной логикой. И один символ тут не должен вводить в заблуждение.
В-четвёртых можно пример, как будет выглядеть код аналогичный
есть у меня подозрение, что вопросиком тут не отделаешься. Конечно на выходе нужен именно результат над списком чисел, а не список результатов над числами.
vsb>>OOM в жаве это отдельная иерархия, но в целом — да, если отвечать на вопрос — пытается. И у него скорей всего получится, т.к. на нижнем уровне там всё используется в пулах преаллоцированных. Хотя, конечно, в условиях OOM всё будет плохо. У меня такой ситуации практически не бывает, но если про это задумываться, я при OOM предпочёл бы просто завершить процесс.
_>Именно! И как раз для таких ситуаций исключения (или паники) подходят идеально.
Насчёт исключений — хз. В жаве есть какой-то флажок, который при первом же OOM-е просто завершает процесс вместо выбрасывания исключения (и вроде хипдамп пишет). Вот это правильный подход и если бы мне не было лень это прописывать, я бы его прописывал.
_>>>А что именно неудобно в работе с Result? vsb>>Ну в го неудобно то, что там под каждым вызовом функции еще 3 строки на обработку err. В расте сахарок сделали, но всё равно везде Result-ы мусорят же. Зачем мне это видеть.
_>Ну тут есть довольно простой ответ, через встречный вопрос. ))) Вот допустим ты используешь механизм исключений для обработки обычных ошибок. Можешь ли ты взяв произвольную функцию в коде точно перечислить список ошибок, который она может вернуть?
Нет, конечно (ну если не считать throws, который был плохой идеей).
Но зачем? Всё, что я знаю — что он может кинуть Exception. Если мне нужно что-то более конкретное — я пойду в нужное место и посмотрю.
В Java придумали throws в своё время который как раз позволяет типы выбрасываемых исключений добавлять в сигнатуру функции. Но это оказалось плохой идеей и сейчас эту фичу стараются избегать.
Здравствуйте, vsb, Вы писали:
vsb>Во-первых у каждой функции с ошибками надо возвращать Result вместо конкретного типа. Это как минимум синтаксический шум.
Вместо T возвращаешь Result<T, MyError>
vsb>Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик.
Неявные точки выхода это зло.
vsb>Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
С checked exceptions то же самое. А unchecked это зло.
vsb>
vsb>есть у меня подозрение, что вопросиком тут не отделаешься. Конечно на выходе нужен именно результат над списком чисел, а не список результатов над числами.
Здравствуйте, T4r4sB, Вы писали:
TB>С checked exceptions то же самое. А unchecked это зло.
Вот только checked exceptions никто не использует, включая новый код в стандартной библиотеке (см. UncheckedIOException который оборачивает IOException). От исторического багажа, к сожалению, избавляться пока не собираются. Про популярные библиотеки и фреймворки вообще не говорю, не припомню ни одной, где использовались бы checked exceptions, если такие и есть, то их мало.
checked exceptions, как и result могут быть полезны как один из инструментов для написания своего кода. Очень редкий инструмент, я сколько пишу, так и не нашел, где это могло бы быть полезно. Ну теоретически могу представить функцию, вызывая которую ошибку обработать надо вообще абсолютно всегда, без исключений (простите за каламбур). Иначе там реактор взорваться может. Там это оправдано — заставлять вызывающего функцию обработать ошибку.
Во всех остальных случаях функция не знает, нужно ли вызывающему коду обрабатывать ошибку, которую она может вернуть вместо результата.
Ещё один артефакт проверяемых исключений в стандартной библиотеке Java это класс URI. У него конструктор кидает исключение, если переданная строка — невалидный URI. Но этот класс часто используется в самой Java. Очевидно, программистам стандартной библиотеки настолько надоело это исключение, что они сделали URI.create(str) — который эту ошибку перекидывает через unchecked exception.
Возможно в java стоило бы добавить синтаксис вроде f(x, y)?; который бы прокидывал checked исключение, как unchecked. Ну тут надо попробовать, может бы и получилось удобно, а может быть и нет.
Здравствуйте, vsb, Вы писали:
vsb>checked exceptions, как и result могут быть полезны как один из инструментов для написания своего кода. Очень редкий инструмент, я сколько пишу, так и не нашел, где это могло бы быть полезно. Ну теоретически могу представить функцию, вызывая которую ошибку обработать надо вообще абсолютно всегда, без исключений (простите за каламбур). Иначе там реактор взорваться может. Там это оправдано — заставлять вызывающего функцию обработать ошибку.
Ну вообще во всех местах где пользователю показывают результат работы функции,
неважно в каком виде: веб страница, desktop GUI, stdout нужен не backtrace,
и какое-то невнятное сообщение, а сообщение о том что случилось и как это исправить.
Для это и нужно контролировать прохождение ошибки сверху вниз и добавлять к ней нужный
контекст.
Re[13]: Почему в расте отсутствует выброс исключений?
Здравствуйте, Zhendos, Вы писали:
vsb>>checked exceptions, как и result могут быть полезны как один из инструментов для написания своего кода. Очень редкий инструмент, я сколько пишу, так и не нашел, где это могло бы быть полезно. Ну теоретически могу представить функцию, вызывая которую ошибку обработать надо вообще абсолютно всегда, без исключений (простите за каламбур). Иначе там реактор взорваться может. Там это оправдано — заставлять вызывающего функцию обработать ошибку.
Z>Ну вообще во всех местах где пользователю показывают результат работы функции, Z>неважно в каком виде: веб страница, desktop GUI, stdout нужен не backtrace, Z>и какое-то невнятное сообщение, а сообщение о том что случилось и как это исправить. Z>Для это и нужно контролировать прохождение ошибки сверху вниз и добавлять к ней нужный Z>контекст.
И где ты это видел? Везде показывают "Ой, что-то случилось". Да и какое пользователю дело до сообщения? Ну потратишь ты год времени на то, чтобы пользователю написало красивым русским языком — "У нас кончилось место на диске и мы не смогли закоммитить транзакцию" или "Сервис Google Maps вернул ошибку, которая, вероятно, связана с отозванным токеном". И что дальше? Всё, что действительно нужно — это информативная ошибка в логе, по которой девопс сможет как можно быстрей понять причину и устранить или передать разработчикам. И эта информативная ошибка называется стектрейс. Всё, что нужно программисту — иногда добавлять к этому стектрейсу контекстную информацию. Чтобы потом проще было понять, что случилось. URL, какой-нибудь ID объекта, который мы пытались вставить и тд.
Если пользователь что-то может сделать, ну ок, тут надо постараться. Но вообще это плохой UX. Не должно случаться таких ситуаций, чтобы действия пользователя приводили к ошибке, которую он сам может исправить. Если пользователь может, значит может и система исправить. Если вариантов исправления несколько, значит плохо проработан workflow.
Здравствуйте, vsb, Вы писали:
vsb>Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик. Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
Это как раз преимущество. Внезапно прилетающее исключение не начнёт ломать код, который к этому не был готов. Мы сразу на этапе компиляции увидим места, которые нужно поправить.
vsb>В-четвёртых можно пример, как будет выглядеть код аналогичный
vsb>
vsb>есть у меня подозрение, что вопросиком тут не отделаешься. Конечно на выходе нужен именно результат над списком чисел, а не список результатов над числами.
Здравствуйте, vsb, Вы писали:
vsb>И где ты это видел? Везде показывают "Ой, что-то случилось". Да и какое пользователю дело до сообщения?
Пользователю, конечно, пофиг. Но явные ошибки всё-таки заставляют задуматься над правильной обработкой: видя список ошибок ты сознательно выбираешь некоторые проигнорировать, какие-то пробросить дальше, из-за каких-то повторить запрос или сделать вообще что-то другое.
Но да, проще писать код не задумываясь над ошибками вообще. А уже по результатам тестирования подпирать костылями try/catch.
Re[11]: Почему в расте отсутствует выброс исключений?
Здравствуйте, DarkEld3r, Вы писали:
vsb>>Во-вторых если функция сейчас не бросает ошибок, а завтра начинает бросать, мне надо менять её тип, потом проходить по всем местам её использования и как минимум добавлять туда этот самый вопросик. Потенциально надо рекурсивно менять тип этой вызывающий функции и так далее.
DE>Это как раз преимущество. Внезапно прилетающее исключение не начнёт ломать код, который к этому не был готов. Мы сразу на этапе компиляции увидим места, которые нужно поправить.
Я не понимаю, что такое "код, который к этому не был готов". У меня есть воспоминания про exception-safety в С++, но там это было обосновано повсеместным ручным управлением памятью, а в современном C++ наверное и это стало не важно. А в Java что такое код, который не готов к исключениям — ну это прям постараться надо, чтобы такой код написать. Если писать в более-менее общепринятом стиле, где нет долгоживущих объектов, а те, которые долгоживущие — те обычно иммутабельные и из мутабельности там максимум — кеши, где с базой работают через транзакции, то исключение может вылетать в любом месте (вообще-то в Java оно и так может вылетать почти в любом месте) и на корректность системы это не повлияет.
Вот сколько пишу на жаве, лет 15 наверное, не припомню ни одного случая, чтобы исключение в одном запросе как-то повлияло на другой запрос.
Re[15]: Почему в расте отсутствует выброс исключений?
Здравствуйте, DarkEld3r, Вы писали:
DE>Но да, проще писать код не задумываясь над ошибками вообще. А уже по результатам тестирования подпирать костылями try/catch.
Дык про что я и толкую. А код надо писать так, как проще. А не так, как сложней. Платят не за обработку ошибок, а за функционал. Мало кто будет платить за сервис, который хорошо показывает ошибки, но у которого не хватает нужного функционала.
И я прекрасно понимаю, что это не универсальное правило. Если я пишу консольный клиент для git-а, конечно он должен выдавать хорошие ошибки. Если я пишу компилятор, он должен выдавать просто превосходные ошибки. Это важно. А если я пишу опердень, то этот опердень должен рассчитаться. А всё, что нужно от обработки ошибок — не испортить базу и адекватно вывалить эту ошибку, чтобы я лично с ней разобрался и исправил баг или входные данные или ещё там что-то. Время, потраченное на перфекционирование с ошибками, это скорей всего время, которое могло бы быть потрачено более полезным образом. А код, который потрачен на это перфекционирование с ошибками это код, который нужно будет сопровождать всю оставшуюся жизнь данной софтины.
А ещё могу добавить, что код, который обрабатывает теоретические ошибки, никто никогда не тестирует. Со всеми вытекающими. Вот когда у тебя код изначально максимально простой, потом тебе прилетела проблема, ты эту проблему в юнит-тесте смоделировал и точечно поставил в нужном месте try-catch, вот это идеально. И кода минимум и тестом покрыт.
Здравствуйте, vsb, Вы писали:
vsb>И я прекрасно понимаю, что это не универсальное правило. Если я пишу консольный клиент для git-а, конечно он должен выдавать хорошие ошибки. Если я пишу компилятор, он должен выдавать просто превосходные ошибки. Это важно. А если я пишу опердень, то этот опердень должен рассчитаться.
Никто не говорил, что обработка ошибок в расте через Result — это серебряная пуля. Она где-то удобна, а где-то нет. Вероятно, что для тех целей, для которых изначально создавался раст, Result был лучше других альтернатив. Ну и никто не заставляет использовать раст для опердней (и не только для них), если есть более удобные языки )
Z>>Ну вообще во всех местах где пользователю показывают результат работы функции, Z>>неважно в каком виде: веб страница, desktop GUI, stdout нужен не backtrace, Z>>и какое-то невнятное сообщение, а сообщение о том что случилось и как это исправить. Z>>Для это и нужно контролировать прохождение ошибки сверху вниз и добавлять к ней нужный Z>>контекст.
vsb>И где ты это видел? Везде показывают "Ой, что-то случилось". Да и какое пользователю дело до сообщения? Ну потратишь ты год времени на то, чтобы пользователю написало красивым русским языком — "У нас кончилось место на диске и мы не смогли закоммитить транзакцию" или "Сервис Google Maps вернул ошибку, которая, вероятно, связана с отозванным токеном". И что дальше?
И пользователь исправит эту ошибку.
И большинство софта с которым я работаю в общем-то "популярные" ошибки пользователя так и обрабатываются как я указал в исходном сообщении.
Если пришел код 401/403 по HTTP то почти любое приложение умеет преобразовать его в диалог повторного
запроса логина и пароля, падение процесса/потока отвечающего за вкладку в браузере приводит к диалогу с предложением
перезапустить вкладку, а не только "ой, что-то случилось".
Большинство рабочего софта (IDE, видео редакторы, фото редакторы) показывают ошибку типа кончилось
место и некоторые даже сразу запускают какой-нибудь системный диалог для удаления ненужных файлов.
Re[4]: Почему в расте отсутствует выброс исключений?
Здравствуйте, flаt, Вы писали:
F>Что значит, обнаружил? Это описывается в "The book", которую нужно прочитать в первую неделю знакомства с языком.
F>Как можно что-то использовать, даже не прочитав документацию? Будь-то ЯП или API.
С яп всё как в жизни — сначала учатся говорить, а уже потом идут в школу и изучают язык на уроках.
Re[15]: Почему в расте отсутствует выброс исключений?
Здравствуйте, Zhendos, Вы писали:
Z>И пользователь исправит эту ошибку.
Для этого ему сначала надо взломать сервер (:
Z>И большинство софта с которым я работаю в общем-то "популярные" ошибки пользователя так и обрабатываются как я указал в исходном сообщении. Z>Если пришел код 401/403 по HTTP то почти любое приложение умеет преобразовать его в диалог повторного Z>запроса логина и пароля
Вот это как раз и делается очень удобно с исключениями. Заводится одно исключение UnauthorizedException которое может бросить кто угодно и которое на уровне общего обработчика преобразуется в соответствующий HTTP-код.
Z>Большинство рабочего софта (IDE, видео редакторы, фото редакторы) показывают ошибку типа кончилось Z>место и некоторые даже сразу запускают какой-нибудь системный диалог для удаления ненужных файлов.
Я про серверный софт пишу всё это время.
Re[12]: Почему в расте отсутствует выброс исключений?
Здравствуйте, vsb, Вы писали:
vsb>Я не понимаю, что такое "код, который к этому не был готов".
Вот, что у в среднем коде с "неожиданным" исключением произойдёт? Оно где-то на верхнем уровне будет записано в лог и всё. Иногда действительно ничего лучше сделать нельзя, но очень часто можно. Хорошо если мы говорим о "запросах" — тогда проблемный просто будет игнорироваться до того как программист посмотрит логи и пофиксит проблему. С резалтами же не надо ждать баг-репортов от пользователей.
Re[13]: Почему в расте отсутствует выброс исключений?
Здравствуйте, DarkEld3r, Вы писали:
vsb>>Я не понимаю, что такое "код, который к этому не был готов".
DE>Вот, что у в среднем коде с "неожиданным" исключением произойдёт? Оно где-то на верхнем уровне будет записано в лог и всё. Иногда действительно ничего лучше сделать нельзя, но очень часто можно. Хорошо если мы говорим о "запросах" — тогда проблемный просто будет игнорироваться до того как программист посмотрит логи и пофиксит проблему. С резалтами же не надо ждать баг-репортов от пользователей.
А зачем их ждать? Настраиваешь алерты по новым эксепшнам и всё. Вылетел эксепшн — пришла смс, открыл лог, посмотрел, пофиксил.
Что тут раст предлагает, я пока тоже, честно говоря, не понимаю.
Ну сделал ты инсерт в базу. Отдала тебе базу ошибку какую-то. Код такой-то, текст ошибки такой-то. И что дальше? Кодов ошибок в БД тысячи. Причин, по которым не сработал инсерт — тоже много. В итоге так же отдашь 500 и всё. Или панику кинешь. А когда в эксплуатации увидишь, что там конкретная ошибка срабатывает вроде нарушения уникальности, то пропишешь по коду сравнение и обработку, ровно так же, как будет в жаве.
Здравствуйте, vsb, Вы писали:
vsb>И я прекрасно понимаю, что это не универсальное правило.
Это хорошо, тогда у нас нет принципиальных разногласий.
vsb>Если я пишу консольный клиент для git-а, конечно он должен выдавать хорошие ошибки. Если я пишу компилятор, он должен выдавать просто превосходные ошибки.
Но ты почему-то зациклен на "показать ошибку". Все эти заморочки с резалтами они не для того, чтобы раньше, лучше и точнее написать в лог или показать пользователю проблему. Они для того, чтобы ты при написании и чтении кода мог увидеть потенциально проблемные моменты.
Ну и наконец есть штуки вроде anyhow. Я бы сказал, что с ними скорость написания кода практически не отличается от аналога с исключениями. Да, в тексте программы будет чуть больше "шума". И вот именно тут мы и расходимся во мнении. Я не считаю это шумом, а наоборот полезной информацией.
Можно ещё поспорить насчёт того, что на самом деле будет быстрее: один раз посмотреть на возможные ошибки, которые возвращает функциям, и подумать, что с ними делать. Или написать код, проверить его вручную или тестами на ограниченных сценариях, добавить обработку ошибок при необходимости, отдать на тестирование, опять добавить try/catch и т.д. Но объективных метрик у меня, ясное дело, нет. В целом лично мне нравится получать максимум информации из типов, а не полагаться на документацию, которая может быть не идеальной или даже отсутствовать. А ещё документация имеет свойство устаревать.
Ну и снова согласен с тобой: если обработка ошибок в 99% случаев сводится к "игнорируем проблему и пишем на верхнем уровне в лог", то да, можно не заморачиваться.
Re[14]: Почему в расте отсутствует выброс исключений?
Здравствуйте, vsb, Вы писали:
vsb>А зачем их ждать? Настраиваешь алерты по новым эксепшнам и всё. Вылетел эксепшн — пришла смс, открыл лог, посмотрел, пофиксил. vsb>Что тут раст предлагает, я пока тоже, честно говоря, не понимаю.
В идеале, "пофиксить" можно при написании кода, не дожидаясь уведомлений о новых проблемаx после того как новая версия была залита на прод. Понятное дело, это не всегда будет работать, особенно если если брать крайние случаи когда ошибка — это "случалась непонятная хрень".
vaa>Почему в расте отсутствует выброс исключений? Это же удобный способ передачи управления.
Потому что язык молодой, зубы пока молочные. Коренные появятся позже.
Оно так было с большинством языков — исключения появились через N итераций. Исключения (хехе, каламбурчик) были (кажется, в Java с самого начала), но в большинстве случаев исключения появлялилсь много позже, при росте сложности проектов и все более частой необходимости non-local return с возможностью посмотреть исходный call stack. Это не более чем формализация практики, когда error return оборачивают в tuple типа {error, Reason, Location} на каждом уровне из цепочки вызовов (т.н. "bubble wrapping"), по сути создавая call stack врукопашную. Так что и в Rust оно появится. Просто позже.
Re[2]: Почему в расте отсутствует выброс исключений?
