Перепутанный станд.:: runtime_error по сравнению со станд.:: logic_error
Я недавно видел, что повышение program_options библиотека бросает a logic_error если вход командной строки был un-parsable. Это бросило вызов моим предположениям о logic_error по сравнению с. runtime_error.
Я принял тот логические ошибки (logic_error и его производные классы), были проблемы, которые следовали из внутренних отказов придерживаться инвариантов программы, часто в форме недопустимых аргументов внутреннему API. В этом смысле они в основном эквивалентны ASSERT's, но предназначенные, чтобы использоваться в выпущенном коде (в отличие от ASSERT's, которые обычно не компилируются в выпущенный код.) Они полезны в ситуациях, где невозможно интегрировать отдельные компоненты программного обеспечения в сборках отладки/теста, или последствия отказа таковы, что важно дать обратную связь во время выполнения о недопустимом инвариантном условии пользователю.
Точно так же я думал это runtime_errors произошел исключительно от условий во время выполнения за пределами управления программиста: ошибки ввода-вывода, недействительный пользователь ввел и т.д.
Однако program_options, очевидно, в большой степени (прежде всего?) используемый в качестве средства парсинга конечного пользователя вводит, таким образом, под моей умственной моделью он, конечно, должен бросить a runtime_error в случае плохого входа.
Где я иду не так, как надо? Вы соглашаетесь с моделью повышения ввода исключения?
2 ответа
В этом случае я думаю (по крайней мере, по большей части) вы правы, а это неверно. Стандарт описывает logic_error как:
Класс logic_error определяет тип объектов, выдаваемых как исключения для сообщения об ошибках, предположительно обнаруживаемых до выполнения программы, таких как нарушения логических предварительных условий или инвариантов классов.
Аргумент командной строки, который не может быть проанализирован, кажется, не очень подходит для этого.
Напротив, он описывает runtime_error как:
Класс runtime_error определяет тип объектов, выдаваемых как исключения для сообщения об ошибках, предположительно обнаруживаемых только при выполнении программы.
Кажется, это больше подходит.
В текущем проекте стандарта C++0x говорится (пункт 19.2):
1) В модели ошибок, отраженной в этих классах (т.е. типах исключений), ошибки делятся на две большие категории: логические ошибки и ошибки времени выполнения.
2) Отличительной особенностью логических ошибок является то, что они вызваны ошибками во внутренней логике программы. Теоретически, их можно предотвратимы.
3) В отличие от этого, ошибки времени выполнения вызваны событиями, выходящими за рамки программы. Их нельзя легко предсказать заранее.
Вместе с цитатами, приведенными в одном из других ответов, это объясняет, почему Boost.ProgramOptions выбрасывает std::logic_error для предотвратимых ошибок, вызванных "ошибкой, предположительно обнаруживаемой до выполнения программы".