"обработка исключений" vs "обработка кодов возврата"

[Majestio]

D_KEY, хе-хе!

Я всегда за разумный компромисс. Подчёркиваю - разумный! Кодинг в стиле "на давай нафигачим 100500 строчек кода, которые в 3-5 местах нам помогут избежать ошибок" мне не нравится. В любом случае, когда ты из беты вылезаешь в релиз - ты каждую строчку кода анализируешь? Это закон. И если ты видишь, к примеру, игнор кода возврата ошибки, и ничего не делаешь (если нужно) - это чисто твои проблемы. Кстати это ещё один вопрос - а не кинуть ли исключение? И это в плюс в обработку ошибок/ситуаций исключениями.

Сообщение отредактировано: Qraizer - 10.12.24, 18:14

[D_KEY]

Так строчек кода больше не станет. Я не понимаю, о чем ты

[Majestio]

Цитата D_KEY @ 10.12.24, 17:58

Так строчек кода больше не станет. Я не понимаю, о чем ты

Ну так я выше давал ссылку на статью с Хабра. Там чел расписал как по его мнению правильно использовать std::expected - накидал портянку кода без какой-то предметной "нагрузки". Я об этом.

Ну а так да, std::expected, если без извращений хорош. Ho ...

Цитата D_KEY @ 10.12.24, 17:30

Суть-то в том, что "обычный" код ошибки ты можешь проигнорировать случайно и т.п., а тут придется обработать.

А кто же меня заставит? Вот тебе пример, где я взял и не обработал, и ничего мне не пришлось, и получил х3 что:

#include <iostream>
#include <expected>
#include <string>
 
std::expected<double, std::string> safe_divide(double numerator, double denominator) {
    if (denominator == 0) {
        return std::unexpected("Division by zero");
    }
    return numerator / denominator;
}
 
int main() {
    auto result1 = safe_divide(10, 0);
    
    std::cout << "Result: " << *result1 << std::endl;
    
    // Это обработка, которую я убрал
    //if (result1) {
    //    std::cout << "Result: " << *result1 << std::endl;
    //} else {
    //    std::cout << "Error: " << result1.error() << std::endl;
    //}
 
    return 0;
}

Просто std::expected позволяет тягать за собой код ошибки. Более "стандартно", нежели я как-то выше показывал вариант возврата структуры. Вот и все.

[D_KEY]

Цитата Majestio @ 11.12.24, 00:11

Цитата D_KEY @ 10.12.24, 17:30

Суть-то в том, что "обычный" код ошибки ты можешь проигнорировать случайно и т.п., а тут придется обработать.

А кто же меня заставит? Вот тебе пример, где я взял и не обработал, и ничего мне не пришлось, и получил х3 что

Ну конкретно тут косяк дизайна std::expected (ИМХО).
Если ты будешь использовать result.value(), то все будет как я писал. Ты не сможшь пойти дальше, если там нет значения, ты получишь исключение. Просто не используй * при работе с expected, кроме редких случаев, когда точно проверил, что там лежит. Я не знаю, зачем они так сделали.

Сообщение отредактировано: D_KEY - 11.12.24, 13:29

[Majestio]

Цитата D_KEY @ 11.12.24, 13:25

Ну конкретно тут косяк дизайна std::expected (ИМХО).
Если ты будешь использовать result.value(), то все будет как я писал. Ты не сможшь пойти дальше, если там нет значения, ты получишь исключение. Просто не используй * при работе с expected, кроме редких случаев, когда точно проверил, что там лежит. Я не знаю, зачем они так сделали.

Ну вот и я о чём. Но, спасибо, учту.

[Qraizer]

Цитата D_KEY @ 11.12.24, 13:25

Я не знаю, зачем они так сделали.

Затем же, зачем operator[] в std::vector<> при живом-то std::vector<>::at(). Сам заюзал, не проверив, сам и отвечаешь.

Добавлено 11.12.24, 14:05
К слову, отладочная STL от MS этот * не пропустит. Как и operator[] для векторов. В дебаге всё проверяется само, поэтому тормозит безбожно

[D_KEY]

Цитата Qraizer @ 11.12.24, 13:55

Цитата D_KEY @ 11.12.24, 13:25

Я не знаю, зачем они так сделали.

Затем же, зачем operator[] в std::vector<> при живом-то std::vector<>::at(). Сам заюзал, не проверив, сам и отвечаешь.

Я могу понять, зачем так делат для vector. Но для нового класса, еще и предназначенного для ошибок, я бы спрятал беспроверочную версию за отдельным методом (желательно с уродским названием).

[Majestio]

Цитата D_KEY @ 11.12.24, 14:42

Я могу понять, зачем так делать для vector. Но для нового класса, еще и предназначенного для ошибок, я бы спрятал беспроверочную версию за отдельным методом (желательно с уродским названием).

У меня есть предположение ...

С++ никогда не позиционировался как язык программирования с "исключительной поддержкой безопасности". Даже вспомнить спичи про его предшественника Си - про него часто говорили мол это "высокоуровневый ассемблер". Вывод? Простой. С++ предоставляет сперва самые быстрые варианты обработки. И только потом "помогает" в случае х3 чего контролить процесс исполнения. Простой пример. Ты явно задаешь вектор из 16Гб элементов, явно и строго! Зачем тебе в этом случае контролить счётчик индексов, чтобы он не вышел за диапазоны? Для этого и нужны методы без проверок, они сокращают время исполнения.

Но тебе ни кто не запрещает влепить операторы с контролем. Только в продакшене это кому-нить будет нужно?!

[Qraizer]

После покрытия тестами – нет. Но покрытие тестами должно быть 100%. Дорого? Да.

Добавлено 13.12.24, 16:02
P.S. Дабы предотвратить избыточный флейм. Покрытие тестами не гарантирует отсутствия ошибок, оно гарантирует лишь поведение кода совпадающее с описанным. При этом описание не коррелирует с качеством реализованной архитектуры. Отсутствие ошибок проектирования обеспечивает верификация, которая опирается на тестирование как один из этапов своих процедур. Вот это по-настоящему дорого. И даже она не гарантирует совпадения спроектированного с ожидаемым, это задача валидации.
Есть такая вся из себя супер-пупер безопасная и строгая Ада. Практически не используется. Флай-код обычно – это даже не куда как более развитые в этом отношении Плюсы, а абсолютно небезопасные и весьма лояльные к программерским сумасбродиям C и капелька ассемблера. Несложно догадаться, почему.

Сообщение отредактировано: Qraizer - 13.12.24, 16:04

[Majestio]

Цитата Qraizer @ 13.12.24, 15:51

После покрытия тестами – нет. Но покрытие тестами должно быть 100%. Дорого? Да.

Не совсем понял. В языках программирования нет понятия "покрытие тестами". Это есть в методах разработки и введения в эксплуатацию, не?

[Qraizer]

Цитата Majestio @ 13.12.24, 16:03

В языках программирования нет понятия "покрытие тестами".

А "продакш" разве есть? Вопрос в том, что изменяется, если отключить проверки. Ответ прост: безопасность не увеличивается, но может уменьшиться. Для "продакшна" важно, чтобы не уменьшилась, а это возможно лишь тогда, когда доказана их избыточность. Тесты на это ...ну, способны.

[Majestio]

Цитата Qraizer @ 13.12.24, 16:06

А "продакш" разве есть? Вопрос в том, что изменяется, если отключить проверки. Ответ прост: безопасность не увеличивается. Для "продакшна" также важно, чтобы не уменьшилась, а это возможно лишь тогда, когда доказана их избыточность. Тесты на это ...ну, способны.

Согласен на 114%! Но это не отменяет того, что C++ (равно как и Си) ... сперва ратует за производительность, а уже во вторую очередь - за "безопасность" (которую и нужно шерстить тестами). Это я к чему? Везде во всех либах С++ "стремится" к производительности, и тут внезапно ДиКей запустил "желалку"! Мол, а "давайте все проверять по умолчанию!". И я тут против. Не для такого как "он" Си писались, "перестраховщик"!

Добавлено 13.12.24, 16:19

Цитата Qraizer @ 13.12.24, 16:06

А "продакш" разве есть?

Конечно! Его другое имя - "релиз". Т.е. всё то, что не дебаг. Издеваесся?

[Qraizer]

Цитата Majestio @ 13.12.24, 16:16

Везде во всех либах С++ "стремится" к производительности, и тут внезапно ДиКей запустил "желалку"! Мол, а "давайте все проверять по умолчанию!". И я тут против. Не для такого как ты Си писались, "перестраховщик"!

Именно. Я вообще не понимаю назначение этих вот MISRA. Либо ты пишешь фигофину, надёжность которой по большому счёту ничего не решает. Тогда можешь для пущего эффекта натравить на неё MISRA и всякие там стат.анализаторы. Только зачем? Либо ты пишешь серьёзный продукт, и тогда будь добр обеспечить его надёжность. ИМХО проще взять Плюсы и задействовать их потенциал безотказного кодинга на полную. Кодревью будет достаточно, чтобы не прошляпить самые очевидные промахи, а с остальным разберётся функциональное тестирование. Для Cей или консервативных Плюсов придётся тестировать куда глубже, без модульных обойтись не получится, а обычный вчерашний выпускник онлайн курсов тестирования просто охренеет, поймёт, что его ничему не научили толком, и пойдёт запивать потраченные к₽ водкой. И опять же причём тут MISRA, непонятно.
Если ты обеспечиваешь качество, то какая разница, как оно написано. По факту MISRA требует отказаться от всего, ради чего C/C++ выбирают, ну и зачем тогда их выбирать? Пишите на Паскале или Питоне. Только от архитектурных и алгоритмических багов ни язык, ни MISRA вас всё равно не спасут. А если всё функциональные (хотя бы) тесты дают добро, то все проверки можно убрать и не париться.

Добавлено 13.12.24, 17:00
Упомянутая выше Ада как раз и нафик никому не сдалась по этой причине. Да, строгая, да, безопасная. Компилер мало что пропустит, а остальное чекается в ран-тайм. Только толку от этого, если в коде программер вместо sin() случайно вкопипастил cos() и не поправил. Без тестирования всё равно не обойтись, и внезапно выясняется, что все ран-тайм чеки, жрущие до 75% ресурсов, уже не нужны, т.к. всё вылизано до идеала. А не отключишь, бо язык вот такой и больше никакой.

Сообщение отредактировано: Qraizer - 13.12.24, 17:00

[Majestio]

Итог? Простой - ни какой язык программирования тебя не спасет от "кодинга по синьке" =) И не нужно ДиКею что-то требовать от Стандарта сверх меры его "компетенции".

Добавлено 13.12.24, 17:02

Цитата Qraizer @ 13.12.24, 16:54

Упомянутая выше Ада как раз и нафик никому не сдалась по этой причине. Да, строгая, да, безопасная. Компилер мало что пропустит, а остальное чекается в ран-тайм. Только толку от этого, если в коде программер вместо sin() случайно вкопипастил cos() и не поправил. Без тестирования всё равно не обойтись, и внезапно выясняется, что все ран-тайм чеки, жрущие до 75% ресурсов, уже не нужны, т.к. всё вылизано до идеала. А не отключишь, бо язык вот такой и больше никакой.

+1

[Qraizer]

P.S. В MISRA вообще дохрена вредных правил. Вот быстро в голову пришло что-то с локальными переменными, чтобы они мол назывались не так, как глобальные. А то ай-яй-яй случайно можно заюзать не то, что думаешь заюзать. Та ёлки ж! индустрия 40 лет вынашивала правило всё локализовывать по максимуму как раз ради того, чтобы не влиять на глобальный контекст, когда оно не нужно. И тут приходят авторы правил MISRA и говорят вы все эти 40 лет были неправы. Ага, счас.

Сообщение отредактировано: Qraizer - 13.12.24, 17:06