Что вы делаете при неудачном close?

Одна из осмысленных вещей что можно сделать - retry every X seconds

Логично, хотя и довольно специфический кейс. Впрочем, с SQL-транзакциями, падающими с retriable-ошибками, я так делаю.

Этого делать вообще никогда нельзя ))

Ну дык close() частенько в деструкторе и вызывается. И логировать его ошибку… ну такое: (1) либо на глобальный лог завязываться, либо тащить лог зависимостью; (2) лог должен быть noexcept, что приводит к вопросу о проездном.

а что говорит статистика ошибок на close ?

По статистике все, кто ел огурцы, умирали.

а что говорит статистика ошибок на close ?

Не по вероятности оценивать надо, а по возможному ущербу. Если мы чего то не видели, то из этого не вытекает, что этого быть не может. Откуда вообще пошло такое понятие «черный лебедь»? Европейцы долго считали, что таких не бывает) Пока в Австралии не встретили.

Ошибки делятся на два группы: ожидаемые и нет.

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

Ошибки делятся на два группы: ожидаемые и нет.

Это мало полезная классификация.

Самая полезная классификация. Происходящее делиться на две категории: то, на что мы повлиять можем, и то на что повлиять не можем. Затрачивать усилия на вторую категорию неверно - затраты есть, а пользы нет.

присвоить вероятность возникновения

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

В случае с close/EIO ошибко можно зафиксировать, но не исправлять, пока не появится больше инфы о причине её возникновения.

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

Самая полезная классификация. Происходящее делиться на две категории: то, на что мы повлиять можем, и то на что повлиять не можем.

Если мы говорим о ближайшем будущем то последнее множество близко к пустому. Всегда приходится принимать решения «что делать?». Зачастую приходится выбирать между «плохим» и «очень плохим» вероятным исходом, но выбор - есть всегда. Имхо.

Не по вероятности оценивать надо, а по возможному ущербу.

Очень правильная мысль (неоднократно Вами озвученная - спешу заметить). Но Вам будет очень трудно её донести до неторгующих людей, особенно если они с опционами дело никогда не имели. Могу только пожелать удачи ))

очень трудно её донести до неторгующих людей

Автор этой концепции, Нассим Талеб как раз и есть трейдер.

Вот именно. Это или ошибка в ядре, либо аппаратный сбой.

Не обязательно. Возможно, просто закончилось свободное место. По крайней мере, нужно сообщить об этом пользователю, а делать вид что всё хорошо.

Если можем продолжать дальше - ну и хрен с ним, если не можем - ну assert, что ещё делать.

Ещё один, который не умеет пользоваться ассертами. Хотя бы ман почитал, что ли. В первом же предложении написано:

$ man assert
...
DESCRIPTION
This macro can help programmers find bugs in their programs...
...

Если close возвращает -1, это run-time error, not a bug.

Не обязательно. Возможно, просто закончилось свободное место

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