Обработка исключительных ситуаций в няшной Сишке

man signal

причем здесь сигналы?

try не нужен, осиль коды возврата.

C:\> man signal
Command not found

обработка исключительных ситуаций, ты ж сам просил.

Жонглируя легендарным оператором GOTO и метками, можно замутить нечто похожее на try / catch и в Цэ.

вы мне тут говорили, что Си это хорошо. Но я не обнаружил в моем компиляторе try.

Тебе никто ничего не обещал. Не нравится --- не юзай.

Вообще, пшёл вон отсюда с таким тоном!

Обычно жонглируют longjmp'ами.

Обработка исключительных ситуаций в няшной Сишке

goto

try/catch в си делается библиотекой, но не имеет смысла.

Дятлы эти Керниган и Ричи, наверняка у них и гигабайта памяти на двоих не было.

а это ведь важнее локальных переменных, да.

Аргументировано, ничего не скажешь.

исключительные ситуации обрабатывает ОС, посылая SIGSEGV и прочие сигналы :)

ну тогда
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680657(v=vs.85).aspx

:)

Без деструкторов и/или сборки мусора исключения не слишком-то полезны.

Если очень хочется именно эксепшенов, то можно выстроить что-то такое: http://www.on-time.com/ddj0011.htm

А вообще вменяемая обработка ошибок зиждется на goto, типа такого: http://www.codealias.info/technotes/error_handling_paradigm_for_c_programs

djenterprise

Тьфублин, перед кем я распинаюсь..

man setjmp longjmp http://en.wikipedia.org/wiki/Setjmp.h раздел Exception handling

пользователи windows должны страдать.
Это же аксиома.

Too fat!

Ну и не лезь тогда в Си. Других языков тебе что ли мало?

Почему-то мне кажется, что ты и в линуксе много чего «не обнаружил».

Лучше возвращайся на свой путь.

А еще толще смог бы?

А ещё нужно вручную выделять память, обосраться.

Жонглируя легендарным оператором GOTO и метками

Расстреливать урановыми пулями, вымоченными в кураре.

Ты не осилил goto.

господа, речь идет и не про Линукс, и не про Windows

это вообще прибор. Так вот в интерпретаторе Бейсика есть возможность обработки Basic Runtime Error (деление на ноль):

ON ERROR GOSUB 10
A = 1/0
PRINT "OK"
RESTART
10 PRINT "Division by Zero"
RETURN

а в Си - нет!

goto хороший оператор, просто не надо им перебарщивать, в некоторых случаях он уместен, например в ядре Linux много goto в драйверах потому что позволяет в правильном порядке и с правильного места делать обратную деинициализацию, не перебарщивая тоннами if-ов, да и с goto иногда проще

Тебе уже сказали: man signal.

setjmp

A = 1/0

msvc такое вообще не скомпилирует: «error C2124: divide or mod by zero».

а gcc скомпилирует и программа вылетит. но может оно так и правильно. дробовиком можно прострелить ногу, но ведь на охоту с томиком Шекспира не ходят.

да и если написать «1./0.», то получится вполне себе «inf». и никаких исключений.

Так этот ноль может получиться не так явно.

msvc такое вообще не скомпилирует: «error C2124: divide or mod by zero».

Феерично полезная фича. Часто в коде напрямую на ноль делишь?

это был модельный пример

Всякие деления на ноль обрабатываются с помощью сигналов в Linux, либо SEH в Windows.

А больше в Си нет и исключительных ситуаций! Всякие ошибки записи в файл, ошибки открытия файла и т. п. не являются критическими и вообще программе на Си они как-то не мешают. Если есть необходимость проверить успешность операции, то используется анализ кодов возврата функций. Например, что-то такое:

FILE *file = fopen("./my-file.txt");
if (file) {
        ... тут работа с файлом ...
} else {
        fprintf(stderr, "Ааааа! файл не открылся! это исключение! мы все умрём!111");
}

Си это мощный инструмент для более низкоуровневого программирования (не случайно там ООП нет) и он не должен городить за программиста лишние абстракции - с точки зрения процессора ошибка открытия файла не является чем-то стоящим, а вот деление на ноль или доступ к некорректному указателю являются порождают аппаратные исключения, которые обрабатывает ОС и посылает сигнал приложению.

Не нужно. А вот отсутствие computed goto по дефолту напрягает.

В го пофиксили:

result, err := DoSomething()
if err != nil {
    // исключительная ситуация
}

Ничем не отличается от

result = DoSomething(&err);
if(err) {}

а ещё в процессоре может не быть исключений вообще

Ничем не отличается от

Ну так го не привнёс никаких принципиально новых фич. Он собрал старые, хорошие фичи и прикрутил к ним читаемый синтаксис.

Что, в свою очередь, тоже ничем не отличается от нормального варианта:

rc = DoSomething(&result);
if (!rc) { }

Так этот ноль может получиться не так явно.

А может и не получиться, если тщательней кодировать.

Капитан.

Феерично полезная фича. Часто в коде напрямую на ноль делишь?

Фича? Логику разработчиков понять несложно. Думаю, они пытаются вычислить константу на этапе компиляции и сообщают об ошибке явно.

Хотя, если допустить, что код можно модифицировать, то желательно, конечно, чтобы такое было ворнингом.

В этом модельном примере было бы проще проверить переменную на ноль, чем городить обработчики исключений.

Если исходить из того, что такая ситуация действительно исключительная, то будет лучше, если программа упадет. Чтобы она при этом не испортила нужные данные, можно воспользоваться сигналами/SEH и/или чем-то таким, на уровне ОС. Ну или не допускать порчи в принципе.

желательно, конечно, чтобы такое было ворнингом.

Вот так правильнее, да.

Хотя при сильной оптимизации действительно может попытаться посчитать при компиляции то, что может посчитать.

Goto превращает логику программы в запутанное говно, хоть как ты его осиливай. Если программист употребляет goto, значит, он не умеет обращаться с алгоритмами.

Если программист употребляет goto, значит, он не умеет обращаться с алгоритмами.

ko-ko-ko

Позвольте, а разве try..catch - это не фишка плюсов? Я вообще не припоминаю в чистом Си такого.

Есть в сети прекрасные статьи, которые разъясняют, когда уместно использовать goto, не превращая программу в запутанное говно и даже более того - делая её читабельнее.

И если уж goto так вреден, какого чёрта его пихают во все подряд языки?

а мужики-то не знают! пойду расскажу, посмеемся вместе.

Есть в сети прекрасные статьи

вроде бы торвальдс подобный вопрос освещал, вот только не помню где именно.