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.

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

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.

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.

Has been done.