Каковы хорошие способы использования longjmp/setjmp для обработки ошибок C?

Взгляните на этот пример/руководство:
http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

Если вы беспокоитесь об очистке ресурсов, вы должны серьезно задуматься о том, являются ли longjmp() и setjmp() хорошей идеей.

Если вы проектируете свою систему распределения ресурсов таким образом, чтобы на самом деле ее можно было аккуратно очистить, тогда все в порядке, но такой дизайн имеет тенденцию быть сложным и, как правило, неполным, если на самом деле стандартные библиотеки, которые использует ваш код, сами выделяют ресурсы, которые должны быть выпущеным. Он требует чрезвычайной осторожности, и, поскольку он не совсем надежен, он не подходит для долго работающих систем, которым, возможно, придется пережить многократное использование вызовов setjmp()/longjmp() (они будут просачиваться, расширяться и, в конечном итоге, вызывать проблемы).

Symbian реализовал свой механизм Leave с точки зрения longjmp(), и это служит хорошим обзором всего, что вам нужно сделать.

Symbian имеет глобальный «стек очистки», который вы нажимаете и извлекаете из того, что хотите очистить, если произошел скачок. Это ручная альтернатива автоматической раскрутке стека, которую делает компилятор C++ при возникновении исключения C++.

У Symbian были «ловушки-ловушки», в которые она могла прыгнуть; они могут быть вложенными.

(Недавно Symbian переосуществила его с точки зрения исключений C++, но интерфейс остался без изменений).

В целом, я думаю, что правильные исключения C++ менее подвержены ошибкам кодирования и намного быстрее, чем ваш собственный эквивалент C.

(Современные компиляторы C++ очень хороши в исключениях с «нулевыми издержками», когда они, например, не выбрасываются; longjmp() должен хранить состояние всех регистров и т. д., даже если прыжок не выполняется позже, поэтому принципиально никогда не может быть таким быстрым как исключения.)

Использование C++ в качестве лучшего C, где вы принимаете только исключения и RAII, было бы хорошим путем, если бы использование longjmp() для эмуляции исключений вызывало у вас искушение.

Я нашел только одно применение для setjmp()/longjmp(), и это не было связано с обработкой ошибок.

На самом деле нет необходимости использовать его для этого, поскольку его всегда можно реорганизовать во что-то более простое для понимания. Использование setjmp()/longjmp() очень похоже на goto в том смысле, что им легко злоупотреблять. Все, что делает ваш код менее читаемым, в целом является плохой идеей. Обратите внимание: я не говорю, что они плохи по своей сути, просто они могут привести к плохому коду легче, чем альтернативы.

FWIW, единственное место, где они были бесценны, - это проект, который я делал на заре индустрии (временные рамки MS-DOS 6). Мне удалось собрать совместную многопоточную библиотеку с использованием Turbo C, которая использовала эти функции в функции yield() для переключения задач.

Я почти уверен, что не прикасался к ним (или не имел необходимости) с тех пор.

Исключения — гораздо лучший общий механизм, но в темные дни прошлого C я написал эмулятор процессора, который включал командную оболочку. Оболочка, используемая для установки jmp/longjmp для обработки прерывания (т. е. процессор работает, и пользователь нажимает break/ctrl-c, код перехватывает SIGINT и longjmp обратно в оболочку).

Я использовал setjmp/longjmp достаточно аккуратно, чтобы выйти из обратного вызова, не прокладывая путь вверх по другим уровням библиотеки.

Этот случай (если я правильно помню) был, когда код внутри синтаксического анализатора, сгенерированного yacc, мог обнаружить (несинтаксическую) проблему и хотел отказаться от синтаксического анализа, но предоставить достаточно полезный отчет об ошибке обратно вызывающей стороне на другой стороне весь сгенерированный yacc код. Другой пример был внутри обратного вызова, вызванного парсером Expat. В каждом случае были и другие способы сделать это, но они казались более громоздкими и неясными, чем просто спасение таким образом.

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

Делаете это в контексте многопоточного программирования? Я уверен, что это не невозможно, но О-о-о, доставайте свою семейную пачку аспирина сейчас же. Вероятно, разумно держать пары setjmp/longjmp как можно ближе друг к другу. Пока совпадающая пара setjmp/longjmp находится в одном потоке, я ожидаю, что все будет в порядке, но... будьте осторожны.