Наилучшая стратегия обработки ошибок в Си

Вот, например, Ариан-5 - надежный софт. За 20 лет - один сбой.

http://www.s1m0n3.org/s0cr4t3s/main/data/ariane5_final.pdf

Макаки отключили проверки в Аде, чтобы софт не лагал...

Интересно, при чем тут обработка ошибок в Си?

Макаки отключили проверки в Аде

Вообще-то наоборот - проверка сработала.

Интересно, при чем тут обработка ошибок в Си?

Тут - не при чем.

Мне нравится выражение, что если бы спецификации были полными, исчерпывающими и непротиворечивыми, то сами спецификации были бы программами. Так что, не стоит некоторым товарищам преувеличивать роль спецификаций.

Кстати, не Союз, а точнее, Фрегат не справился из-за физико-математической ошибки. Сама постановка задачи или численные методы подвели на новых необычных условиях. К самому программированию это имеет малое отношение.

Вообще-то наоборот - проверка сработала.

Блин точно. Вот он вред эксепшонов!

Пофиксили, кстати, тоже смешно: https://github.com/ICTeam28/ProgramAnalysis/blob/master/summaries/stories/ari...

Входные данные надо валидировать.

Мне нравится выражение, что если бы спецификации были полными, исчерпывающими и непротиворечивыми, то сами спецификации были бы программами. Так что, не стоит некоторым товарищам преувеличивать роль спецификаций.

Где-то даже xkcd был на эту тему...

Я бы спросил, что в твоем понимании «детерминированное поведение», но подозреваю, что услышу очередную псевдоакадемическую трескотню.

Программа, поведение которой однозначно определено, и которое можно описать до запуска программы.

Первый и второй, если нужен третий - лучше не пиши на С.

Первый способ самый универсальный. Так сделан N-API в Node.js. Это даже лучше, чем исключения в цепепе.

и да, я не публикую зарплату, я не хочу вас опечаливать.

Меня сложно опечалить, можно публиковать.

У многих сишников просто синдром утенка, они не понимают что можно по-другому. Потом случайно натыкаются на Visual Studio и писают кипятком, после своего вима.

У студии только intellisense, который си не нужен и никак не заметит инструменты, доступные в виме. Так что ты сам знаешь кто. И вообще, говори за себя, чушка.

я уже видела VS. ещё когда под маздай программировала. именно тогда я открыла для себя CodeBlocks и с радостью стала использовать его вместо этого жуткого монстра. так как CodeBlocks кросплатформенный, то я его сначала под маздаем на работе использовала, потом для кроссплатформенного программирования, а потом уже когда полностью и дома и на работе перешла на линь - уже просто на лине. у него были мелкие недостатки, главным образом связанные с криворукостью некоторых разработчиков. но сейчас он вроде стал стабильнее. недавно вот из транка его в очередной раз собрала. отлично работает! и не вставляет в результирующий код всякие анальные зонды, в отличие от VS. я в CodeBlocks даже для микроконтроллеров писала, и на ассемблере проекты. причём прописала там и прошивку, и всё нужное, он настраивается, как конструктор. в этом его прелесть. и он лёгкий! его даже можно носить с собой на флэшке. а всякие монстрозные поделия мелкомягких меня никогда не возбуждали.

Где-то даже xkcd был на эту тему...

http://www.commitstrip.com/en/2016/08/25/a-very-comprehensive-and-precise-spec/

Я не рекламирую VS, я говорю что ее удобство несравнимо с обычными тулами среднего сишника. CodeBlocks нормален для мелких проектов и студенческих поделок. Ковырял его пару лет назад, не думаю что он сильно изменился.

Пример - как мне запустить вот этот конкретный юнит тест из сета? В VS элементарно (как и в любом нормальном IDE). А, точно, сишники же не умеют в юнит тесты.

Ммммм, что мешает тебе запустить вот этот конкретный юнит-тест из сета в виме, чушка? Видимо то, что ты чушка.

Пример - как мне запустить вот этот конкретный юнит тест из сета? В VS элементарно (как и в любом нормальном IDE). А, точно, сишники же не умеют в юнит тесты.

Если сишники не умеют в юнит-тесты, то после того, как они пересаживаются в VS, они что перестают быть сишниками и, поэтому, начинают уметь в юнит-тесты?

Если сишники не умеют в юнит-тесты, то после того, как они пересаживаются в VS, они что перестают быть сишниками и, поэтому, начинают уметь в юнит-тесты?

Visual Studio - это замечательная IDE. Однако она не только для разработки на C или цепепе. Она, в первую очередь, для C#. Также она для Visual Basic, Пайфона, JavaScript.

Инструмент располагает. В С юнит-тесты есть.

после того, как они пересаживаются в VS, они что перестают быть сишниками

Таки да, перестают. VS не умеет компилить Си-код. Только C++.

Или научилась внезапно?

Таки да, перестают. VS не умеет компилить Си-код. Только C++.

Говорят, что цепепе является надмножеством C?

Откуда вы беретесь? Есть в MS VS поддержка сишки, и очень давно.

89? или ты про шланг?

Как включить? Когда добавили?

Пример - как мне запустить вот этот конкретный юнит тест из сета?

из консоли. 99% вещей делаются в консоли. и не нужны для этого никакие монстрозные софтины. мышевозенье вообще непригодно для серьёзной работы, особенно для крупных проектов. IDE нужно, чтобы редактировать код. всё остальное делается в консоли. и чем больше проект, тем более вероятно он собирается на билд серверах, а не в каких-то там «студиях». а это значит автотулзы и консоль, без вариантов.

Хм... Судя по поверхностным тестам, вполне себе ничего. На VLA споткнулся, но с VLA я всё равно внятно работать не умею, и поэтому не использую.

Элементарно:

1. Каждый тест - отдельный проект.

2. В постбилдстепс прописываем запуск теста.

3. Если надо запустить конкретный тест - просто жмешь ребилд на конкретном проекте.

4. Если надо запустить все тесты - жмешь ребилд воркспейс.

5. ??????

6. Юниттесты в Code::Blocks!!!

СПС! Джва года искал!

2000 проектов на воркспейс потянет? А 4000?

Пример в студию. С любой библиотекой.

200 %

После таких постов даже начинаешь сомневать что вы - девушка :-)

Умела изначально. Тот же маздайный кернел частично компилится в С-режиме. Если мне не изменяет память то С-режим включается правильным расширением имени исходника. При этом например выключается манглинг имен и всякое такое.

MYERROR create_some_thing (SOME_THING **ptr/*other parameters*/);

После того как С научился возращать структуры через стэк я бы сделал вот так:

typedef struct {
    int result;
    int err_code;
    char *err_str;
} MYERROR;

MYERROR create_some_thing (SOME_THING **ptr/*other parameters*/);

Еще как вариант посмотреть на использование GError в GLib

Речь о поддержке стандарта. Там вроде даже по с89 вопросы есть. Не говоря уже про с11.

Согласен. Так и есть - на стандарты положен болт

Ты просил как сделать юнит-тесты с возможностью запуска одного из них по выбору - тебе показали, точка.

Кстати, как в случае 2000 тестов ты собрался выбрать только один из них?

тебе показали

Пока твой метод не тянет как минимум 2к тестов, то это херня.

как в случае 2000 тестов ты собрался выбрать

Внезапно, в нормальных фреймворках тесты можно разбить на категории. Или к каждому проекту в воркспейсе делать тестовый проект.

наилучшая стратегия избавления от ошибок на C - это писать на нём как можно меньше. а всё остальное писать на Limbo/Golang

Про голанг согласен.

всё остальное писать на Limbo/Golang

Извращенец чертов!

Так и хочется стать по стойке «смирно» от такого серьезного, даже бескомпромиссного, отношения к разработке. Но память о том, что эти слова произносит лиспер, заставляет издевательски ухмыляться.

monk, тут не могу не улыбнуться проходя мимо)

Пока твой метод не тянет как минимум 2к тестов, то это херня.

Где пруфы, маня?

В Go обработка ошибок не сильно лучше C.

да ну? а по-моему defer очень круто меняет ситуацию.

Это не обработка ошибок, а очистка ресурсов.

Круто меняет ситуацию RAII. defer не сильно отличается от cleanup attribute в gcc, да и от паттерна с goto на освобождение ресурсов. Но удобнее, да.

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

cleanup attribute в gcc

не ковенционно. давай плодить костыли дальше, вместо того, чтобы признать, наконец, что есть более удобные и безопасные инструменты.

да и от паттерна с goto на освобождение ресурсов

и попытаться не потерять мысль «что, от куда и куда растёт»..

defer такой же костыль(а так же finally, например). Просто более удобный=)

Нормальный подход тут - RAII. Ну или на худой конец context managers(python), try-with-resources(java), using(c#).

Всю тему не читал, но можешь сделать как сделано с интерфейсами COM/OLE.
Т.е.

ErrorRecord func(T_1 param1,..T_N paramN, out T_OUT &out);