Code review comment for lp:~vanvugt/mir/fatal-error

Additional state reporting and logging is a part of the solution. But not all of it.

There are two sets of users to consider here:

1. the users of Mir - shell/server developers exemplified by U8 and U-S-C
2. the users of U8

The former are the ones that should decide whether an abort is acceptable behavior for their program. Not the developers of Mir.

It may even be argued that the latter should be offered a choice too. Then beta testers can run with one option and final users with another.

For example, an option like this:

    --on-fatal-error arg (=throw) Action to take on a fatal error [throw|abort|break]

In U8 and/or U-S-C development we can change the default to "abort" in order to ensure better diagnostics. But reconfigure in a production environment to "throw".

With "throw" there should be a bespoke a FatalError exception that is understood by mir::report_exception() and reads:

    to get additional debug information in a core:
       $ ulimit -c unlimited
    and rerun with "--on-fatal-error abort"