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

> Another solution, trying to combine the best of both worlds, was discussed
> during standup today: let the client of the library decide whether runtime
> errors like the ones discussed in this MP should abort, throw or do something
> completely different.
>
> By default the library should be polite with client code and throw exceptions.
> Certain clients, which can safely handle Mir abort()s and from which we want
> comprehensive debugging information, can explicitly configure mir to abort().
> I imagine that both unity8 and USC will want to do that.
>
> "Needs discussion"

We as a library have no way of knowing what else is running in the same process nor whether it is acceptable to terminate the process at any given time. Hence, it is extremely impolite for to abort process unless the client code has caused it in some way. (I.e. either the client has requested the abort or has broken a precondition.)

I'm not saying it is a primary use case, but it is conceivable that a process with another primary purpose spins up a Mir compositor briefly and expects to continue after it closes down. With errors reported via exceptions that is possible, with errors reported by "abort()" it isn't. (FWIW I'd even like it to be fully supported to run multiple Mir servers in a process without an error in one bringing the whole lot down.)

So long as the client code uses the Mir API correctly I don't think we should ever abort. (That doesn't preclude the client installing handlers for "very bad things" into Mir that abort *in client code* with our stack intact.)