История изменений

Что в общем довольно компактно и соответствует подходу golang. Там у людей, из-за отсутствия исключений навернута целая философия по обработке таких ошибок. Как-то живут люди.

В Golang просто нет variant, а с variant всё это становится элегантнее, особенно если использовать поверх variant шаблон вида std::expected. В Golang типичный паттерн: после возврата функции проверить `err != nil` условии if-блока обработки ошибок, так если булев оператор `std::expected` будет возвращать true только при наличии внутри корректного значения, то получится точно такая же проверка.

Для себя с исключениями я давно решил так:

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

Шаблонно-функциональную магию из поста автора считаю задротством, таким банально пользоваться неудобно. Лучше переписать в явном стиле, пусть даже будет чуть-чуть дублирования кода. Вместо макроса просто объявить серию функций-обёрток, а также написать внутреннюю процедуру `throw_errno_if`, которая принимает условие и текст (чтобы знать, какой метод API привёл к выбросу). Эта процедура и сократит код функций-обёрток до 3 строк на каждую.

Что в общем довольно компактно и соответствует подходу golang. Там у людей, из-за отсутствия исключений навернута целая философия по обработке таких ошибок. Как-то живут люди.

В Golang просто нет variant, а с variant всё это становится элегантнее, особенно если использовать поверх variant шаблон вида std::expected. В Golang типичный паттерн: после возврата функции проверить `err != nil` условии if-блока обработки ошибок, так если булев оператор `std::expected` будет возвращать true только при наличии внутри корректного значения, то получится точно такая же проверка.

Для себя с исключениями я давно решил так:

• в прикладном коде ошибка в создании файла, чтении данных и т.п. обычно фатальная и закончить крупную операцию не позволяет, поэтому легче бросить исключение и раскрутить стек, некоторые потери производительности в ненормальном пути выполнения допустимы
• в коде демонов, серверов, компонентов ОС те же ошибки обычно терпимы и даже возможны массово, например, при нехватке ресурсов или атаке на сервер, поэтому следует из функции возвращать коды ошибок (а лучше либо код, либо значение, как с `std::expected`

Шаблонно-функциональную магию из поста автора считаю задротством, таким банально пользоваться неудобно. Лучше переписать в явном стиле, пусть даже будет чуть-чуть дублирования кода. Вместо макроса просто объявить серию функций-обёрток, а также написать внутреннюю процедуру `throw_errno_if`, которая принимает условие и текст (чтобы знать, какой метод API привёл к выбросу). Эта процедура и сократит код функций-обёрток до 3 строк на каждую.