>  На то и серверное сетевое приложение, которое работает фактически вечно для обслуживания запросов.

Нет. Реальное серверное приложение имеет документированные возможности, позволяющие остановить его. Возможно ещё перезапустить/перезагрузить конфиги. Серверное приложение _фактически_ не работает вечно, оно регулярно перезапускается после изменения конфигурации или наложения патчей безопасности.

> У вас какая-то другая точка зрения как это реализовать?

Я могу предложить штуки три альтернативы. while(accept()), server.map_connections(|conn| { ... }) и итератор поверх открываемых соединений. Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть. Здесь штатная ситуация (а фейл accept'а -- это, во многих случаях, штатная ситуация) обрабатывается при помощи throw, который используется как нелокальный goto. Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций.

В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо.

Делать надо через Either/Result[1]. Это, по-моему, _напрашивающийся_ подход: когда я фанател C'ями, я пытался такую штуку сделать в C, по-сути изобретя её самостоятельно. Я писал какой-то парсер, который возвращал токены и подвыражения, но при этом любая функция могла завершиться с ошибкой. Из-за отсутствия параметризованных типов пришёл к выводу, что всё это конечно круто, но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред. Сейчас я думаю, что может быть можно как-то на кривой козе макросами объехать ограничения языка, но мне просто C более не интересен, поэтому плевать.

В Haskell'е же, OCaml'е это совершенно нормальный и естественный ход. И в C++ это должно быть естественным ходом -- для обработки ошибок таким образом не нужен никакие замороки с размоткой стека исключениями, обработка происходит явно и довольно удобно (без этого бесконечного засирания кода if'ами и без необходимости для каждого типа предусматривать значение, которое будет аналогом NULL для указателя), она проверяется статически через систему типов, и блин, всё это настолько естественно, даже непонятно сегодня, почему это было не запилить в C в 70-х годах. Пускай даже для этого потребовался бы специально выточенный костыль из-за отсутствия параметризованных типов.

Я не очень понимаю, насколько эти вещи стандартизованы в C++, судя по тексту статьи складывается ощущение, что не стандартизованы, и каждый дpoчит как хочет, а интероперабельность разных API приходится выпиливать лобзиком в каждом конкретном случае. Но там есть ссылки на std::expected и boost::expected, то есть всё не так плохо.

[1] https://hackernoon.com/error-handling-in-c-or-why-you-should...