tag:blogger.com,1999:blog-654279083390275842.post6663110628732066206..comments2024-03-19T12:22:43.654+03:00Comments on Размышлизмы eao197: [prog.thoughts] Какой способ информирования об ошибках мне бы хотелось иметь для написания надежного кода?eao197http://www.blogger.com/profile/17283739752119445290noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-654279083390275842.post-89161756351188638652020-08-15T14:22:20.558+03:002020-08-15T14:22:20.558+03:00Sum types с паттерн матчингом это хорошо, но прота...Sum types с паттерн матчингом это хорошо, но протаскивание ошибки через много слоев/блоков может быть довольно муторным. В этом смысле занятно сделали в современном Окамле: там можно вернуть обычное значение из функции, а можно кинуть исключение из любого ее места, а в вызывающем коде можно проанализировать их вместе. Например, если функция myFunc обычно возвращает option, но может и кинуть исключение, то пишешь<br /><br />match myFunc arg1 arg2 with<br />| Some x -> do_something_with_x<br />| None -> do_something_about_nothing<br />| exception End_of_file -> do_something_else1<br />| exception Err -> do_something_else2<br /><br />А если тут не стал ловить исключение, оно дальше вверх полетит. Dmitry Popovhttps://www.blogger.com/profile/07584454083425330761noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-66787073128214258992020-08-05T14:16:19.214+03:002020-08-05T14:16:19.214+03:00@XX
Насколько я помню, код на Rust можно скомпили...@XX<br /><br />Насколько я помню, код на Rust можно скомпилировать в режиме, когда выброс паники сразу приводит к аборту приложения. Так что если кто-то пишет на Rust-е либу в которой паники бросаются и перехватываются, а затем эта либа попадает в приложение, которое собирается в режиме "treat panic as abort", то приложение накрывается медным тазом при первой же брошенной панике.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-41015311007572987152020-08-05T14:10:37.515+03:002020-08-05T14:10:37.515+03:00> Есть паники. Которые не исключения. И которые...> Есть паники. Которые не исключения. И которые, в принципе, могут сразу приводить к краху всего приложения, без каких-либо шансов на перехват и последующее восстановление.<br /><br />Панику в Rust таки можно перехватить:<br />https://doc.rust-lang.org/std/panic/fn.set_hook.html<br />https://doc.rust-lang.org/beta/std/panic/fn.catch_unwind.htmlXXhttps://www.blogger.com/profile/10464349444066531375noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-28739647315024040752020-08-02T13:42:05.063+03:002020-08-02T13:42:05.063+03:00@eao197
"Ну вот мне сложно придумать сценарии...@eao197<br />"Ну вот мне сложно придумать сценарии в которых нужно знать про noexcept когда пишешь обычный код."<br />скажем исключения запрещены по тем или иным причинам (в атомобильном секторе это распростроненное ограничение)<br />"Компилятор знает, что может бросать исключения." это да, причем просто по сигнатуре без noexcept, но и false positive тоже будут. новерное, ворнинг лучше чем ничего.<br /><br />"Скорее про то, что хотелось бы видеть в гипотетическом "языке мечты"." <br />как вариант:<br />возвращаемое значение вместе с ошибкой и механизм работы с таким упакованным значением. например стандартные алгоритмы принимают и итераторы и упакованные итераторы с ошибкой <br />а исключения для ситуации "все пропало" и надо закрывать/перезапускать приложениеAlexhttps://www.blogger.com/profile/04747978076363326356noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-74503514388326443642020-08-02T12:19:23.749+03:002020-08-02T12:19:23.749+03:00@Alex
> я бы сказал и там и там - зависит от п...@Alex<br /><br />> я бы сказал и там и там - зависит от применения<br /><br />Ну вот мне сложно придумать сценарии в которых нужно знать про noexcept когда пишешь обычный код. Поскольку исключения могут вылететь откуда угодно, то нет смысла выделять из общей последовательности действий noexcept действия.<br /><br />> все равно компилятор не знает кто и что бросает, а раз так то получаем terminate вместо хотя бы стэка.<br /><br />Компилятор знает, что может бросать исключения. Этого вполне достаточно для того, чтобы выдавать предупреждения при попытке написать некорректный noexcept код (т.е. код, который не должен бросать исключения, но использует бросающие конструкции внутри).<br /><br />Знать что именно бросается, кмк, нужно далеко не всегда.<br /><br />> в обшем не понятно как это все реализовать при возможности использовать существующий код...<br /><br />Пост был не столько про то, как делать "правильно" в C++. Скорее про то, что хотелось бы видеть в гипотетическом "языке мечты".eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-85443629401795275382020-08-02T12:13:12.183+03:002020-08-02T12:13:12.183+03:00@eao197
"noexcept нужны не столько для того,...@eao197 <br />"noexcept нужны не столько для того, чтобы писать "обычный" код, сколько для того, чтобы писать код по восстановлению после проблем" я бы сказал и там и там - зависит от применения<br />"Но пока использовать noexcept сложнее, чем хотелось" именно, и не очень понятно как noexcept блок может помочь - все равно компилятор не знает кто и что бросает, а раз так то получаем terminate вместо хотя бы стэка.<br />в обшем не понятно как это все реализовать при возможности использовать существующий код...<br />Alexhttps://www.blogger.com/profile/04747978076363326356noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-42614900927407302372020-08-02T11:55:50.481+03:002020-08-02T11:55:50.481+03:00@Alex
ИМХО, noexcept нужны не столько для того, ч...@Alex<br /><br />ИМХО, noexcept нужны не столько для того, чтобы писать "обычный" код, сколько для того, чтобы писать код по восстановлению после проблем (например, обработчики исключений в catch) и код по очистке ресурсов (деструкторы). Но пока использовать noexcept сложнее, чем хотелось бы именно потому, что "компилятор не знает бросают ли исключения те функции которые вызывается под noexcept". Эту сложность можно попробовать обойти подручными средствами. Но лучше бы иметь помощь от компилятора (например, в виде описанного в посте noexcept блока).eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-59134285653498524372020-08-02T10:56:46.558+03:002020-08-02T10:56:46.558+03:00легаси и многобразие в с++ ставит исключения в иск...легаси и многобразие в с++ ставит исключения в исключительную ситуацию ))<br />1. исключения являются неявной частью интерфейса функции/метода. фактически без чтения документации и надежды на ее корректность тяжело/невозможно написать корректный код который эту функцию вызывает. без доков если функция не noexcept остается использовать catch (...) на каждый вызов. <br />2. noexcept не помогает писать код т.к. компилятор не знает бросают ли исключения те функции которые вызывается под noexcept. т.е. клиенсткому коду хорошо - он взывает уже noexcept а вот тому кто пишет noexcept функции тяжело. да и ответ программы на простую багу типа забыл тут try/catch - terminate<br />3. является ли ошиба исключением или нет решать должен клиенсткий код. например для fmt::format некорректный формат это ужас ужас, а для вас - просто запись в логе. ну некорректная и ладно<br />какие исключения не придумай все равно существующий код не даст перейти на это нововведение. в общем получается как всегда 100500+1 стандарт<br /><br />писал как-то фреймфорк для автомобильного применения. пробовал boost::outcome. в целом понравилось. <br />есть логирование ошибок - удобно и централизованно. не пропустить случайно.<br />ошибка всегда возвращается явно - нет неявного интерфейса.<br />клиентский код решает бросать или нет.<br />[[nodiscard]] дает сообщение что возвращаемое значение нужно обработать.<br />из того что не понравилось - муторно передавать ошибки дальше по стэку вызовов.<br /><br />Alexhttps://www.blogger.com/profile/04747978076363326356noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-2019970747375807092020-08-01T16:10:07.784+03:002020-08-01T16:10:07.784+03:00@Left
Да разве же D -- это дизайн комитетом? Вот ...@Left<br /><br />Да разве же D -- это дизайн комитетом? Вот C++, Ada, Fortran. Может быть даже Java сейчас. Вот это работа комитета. А в D там все зависит от настроения двух-трех человек. Захотелось Брайту сделать betterC и добавить borrow checker в язык. Ну и понеслось. Вне зависимости от того, что другие пользователи D думали по этому поводу.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-8565753511873907592020-08-01T16:06:31.539+03:002020-08-01T16:06:31.539+03:00Дык потому что дизайн комитетом - городят верблюда...Дык потому что дизайн комитетом - городят верблюда с клювом и ластами там где нужен ишак. Ну а как же - нельзя же обидеть Васю, заслуженного специалиста по ластам, и Колю, гения дизайна клювов...Lefthttps://www.blogger.com/profile/17455926726018486961noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-1100819700273040552020-08-01T16:04:53.746+03:002020-08-01T16:04:53.746+03:00@Left
Я не слежу за Kotlin-ом, но вот D, как по м...@Left<br /><br />Я не слежу за Kotlin-ом, но вот D, как по мне, развивается слишком активно и никак не может достичь точки стабильности, при которой его использование в долгоживущих проектах стало бы безопасным.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-21172072909127280972020-08-01T15:39:23.522+03:002020-08-01T15:39:23.522+03:00Ну как бы - Кобол такими темпами не развивается. И...Ну как бы - Кобол такими темпами не развивается. И D тоже не развивается. Я тут давеча рассуждал с товарисчем по поводу развития языка - и говорил ему о том что рискую прослыть ретроградом-ынтырпрайзником - но считаю что в 21м веке язык должен писаться конторой (желательно крупной и с нужным бекграундом) а не комитетом, быть 100% опенсорсным и иметь при этом не слишком много новых идей. Тогда оно имеет шанс взлететь, иначе - помрет.Lefthttps://www.blogger.com/profile/17455926726018486961noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-58202641619712713502020-08-01T15:35:29.214+03:002020-08-01T15:35:29.214+03:00@Left
Я в курсе, что Kotlin начинают использовать...@Left<br /><br />Я в курсе, что Kotlin начинают использовать не только для Android-а. Но говорю с позиции того, что слышу вокруг. А у нас пока Java доминирует, а Kotlin разве что для мобилок.<br /><br />Ну а так-то в мире и COBOL используется, и Fortran. И даже D :)eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-51229195820108483922020-08-01T15:24:41.602+03:002020-08-01T15:24:41.602+03:00Ну как бы - не андроидом единым, везде где есть Дж...Ну как бы - не андроидом единым, везде где есть Джава ее можно смело менять на Котлин, как JS меняется на TypeScript. Мы котлин на серваке гоняем и просто счастливы, волосы стали шелковистыми а пипяка - длиннее и крепче. Но у нас куча С++ кода который бы мы с ОГРОМНЫМ удовольствием на котлине переписали бы...Lefthttps://www.blogger.com/profile/17455926726018486961noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-30237802249255223092020-08-01T15:21:52.830+03:002020-08-01T15:21:52.830+03:00@Left
В наших Палестинах еще маргинальщина. Котор...@Left<br /><br />В наших Палестинах еще маргинальщина. Которая кроме как для программирования под Android больше нигде не видна.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-55530369703266990182020-08-01T15:11:56.525+03:002020-08-01T15:11:56.525+03:00Kotlin сам по себе не маргинальщина уже. А вот Kot...Kotlin сам по себе не маргинальщина уже. А вот Kotlin/native - да, пока еще маргинальщина. Но пилят потихоньку, со счетов списывать рано - давеча вон допилили корутины для native - и пообещали новый memory manager. Очень хотелось бы чтобы взлетело, я бы с радостью с С++ слез бы на него.Lefthttps://www.blogger.com/profile/17455926726018486961noreply@blogger.com