Улучшена обработка отсутствующего / неправильного ключа в boost ::program_options

#c #boost #boost-program-options #boost-any

#c #boost #boost-program-options #boost-любой

Вопрос:

Есть ли способ узнать, какой ключ был задействован, когда происходит сбой вызова, подобного следующему?

 boost::program_options::variables_map vm;
...
int foo_bar = vm["some_key"].as<int>();

Если ключ отсутствует на карте или не конвертируется в int, я получаю довольно неинформативный bad_any_cast, и я не могу знать ничего из следующего:

задействованный ключ
сохраненное значение или даже если оно там есть.
задействованные типы

Я не могу найти какого-либо решения, которое не включало бы ни изменение заголовка boost, ни перенос каждого вызова к вышеуказанному в блок try .. catch. Я думаю, что это распространенная проблема, поэтому, возможно, кто-то еще знает лучший подход.

1. Я полагаю, что примеры, представленные в документации, обычно проверяют каждый используемый параметр if(vm.count("some_key") != 0) , поэтому, похоже, именно так они и предполагали его использовать.

2. Необходимость проверять каждый отдельный ключ далека от идеала, хотя я надеялся на менее подробное решение. Я заметил, что в последних версиях boost можно установить параметр как «обязательный», таким образом вызывая исключение, если ключ отсутствует. Конечно, это не сработает для необязательных значений, и у меня все еще есть проблема с обработкой недопустимых значений

Ответ №1:

Марко,

нет способа улучшить диагностику без изменения библиотеки.

Однако, пожалуйста, обратите внимание, что в целом, я не уверен, что исключения в этом случае должны быть очень подробными: — Если вы используете неправильный тип для доступа к переменной, у вас ошибка кодирования. Вы можете легко отследить это с помощью отладчика — если вы обращаетесь к переменной, которая не существует, вам нужно либо ввести if vm.count, либо использовать значение по умолчанию. Опять же, это, вероятно, ошибка кодирования, которую лучше всего решить с помощью отладчика.

Я согласен, что bad_any_cast — это то, что можно улучшить, но не похоже, что исключение, о котором можно сообщить пользователю, должно быть целью здесь, где исключения являются результатом ошибки кодирования.

1. Спасибо за ваш ответ. На самом деле у меня создалось впечатление, что использование пользователем неправильного значения для параметра приведет к возникновению исключения bad_any_cast, но это не так. Так что да, в этом отношении это, должно быть, ошибка кодирования. Тем не менее, я думаю, что отсутствующее значение можно было бы обработать лучше.