I recently saw that the boost program_options library throws a logic_error
if the command-line input was un-parsable. That challenged my assumptions about logic_error
vs. runtime_error
.
I assumed that logic errors (logic_error
and its derived classes) were problems that resulted from internal failures to adhere to program invariants, often in the form of illegal arguments to internal API's. In that sense they are largely equivalent to ASSERT's, but meant to be used in released code (unlike ASSERT's which are not usually compiled into released code.) They are useful in situations where it is infeasible to integrate separate software components in debug/test builds or the consequences of a failure are such that it is important to give runtime feedback about the invalid invariant condition to the user.
Similarly, I thought that runtime_error
s resulted exclusively from runtime conditions outside of the control of the programmer: I/O errors, invalid user input, etc.
However, program_options is obviously heavily (primarily?) used as a means of parsing end-user input, so under my mental model it certainly should throw a runtime_error
in the case of bad input.
Where am I going wrong? Do you agree with the boost model of exception typing?
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…