RFC: handling of fatal errors

[peterschrammel]

Ultimate goal:

• unify various forms of signalling fatal errors (integer error codes, booleans, exceptions of various raw types)
• move catching of fatal errors to top-level

We've already got invariant_failedt for programming errors. I added two more (naming debatable):

• ui_exceptiont for user input related errors
• system_exceptiont for OS related errors

I put the top-level catch into a class derived from parse_options_baset so that the various tools do not need to duplicate the exception handling code.

This PR is for illustration of the concepts.

[hannes-steffenhagen-diffblue]

IMHO neither system_exceptiont nor ui_exceptiont should derive from logic_error - logic errors are things like out of range access, null pointer access and the like, programmer errors we'd usually catch with invariants. Since these are meant to model things outside of our control (user input errors or OS level exceptions) they should either not derive from a std exception type at all or otherwise from runtime_error.

[NlightNFotis]

@hannes-steffenhagen-diffblue Agreed that the exceptions in b2c6da2 should be subclassing std::runtime_error instead of logic_error.

[NlightNFotis]

I think a large class of errors may be caught by invariants already, but maybe it could be a good idea to have an exception type that signals things gone wrong during analysis, like analysis_errort or something along these lines, for at least some of the errors I have seen in CBMC thus far could neatly fall under this category.

[danpoe]

I think we could remove parse_optionst and include the new code directly in parse_options_baset.

[danpoe]

Since all these exceptions are fatal and shouldn't be caught anywhere else, I wonder whether we should include the exit code in the exceptions. Then the different catch clauses would return via return e.exit_code().

[peterschrammel]

Yes, that could make some sense.

[danpoe]

I think we don't need to derive the new exception classes from any of the standard exceptions. It doesn't seem to have a benefit in this use case and only increases the chance that they get caught inadvertently. We could create a new base class fatal_exceptiont instead that defines the basic interface and then derive from that.

[peterschrammel]

Has been done.