How to deal with client API precondition failures

[Daniel van Vugt]

Indeed, there's a reason why we still have fatal signals in modern 
Unix/Linux. Some mistakes you can't back out of gracefully within the 
scope of your already buggy program.

What we do have is a kernel that will clean up by killing just the 
offending process in its entirety, and leaving a core file so you can 
learn from your mistakes. Also remember to try and keep the core file 
clean and with readable backtraces -- don't handle exceptions if you're 
going to end up raising a fatal signal.

We already have this in the server side: mir::fatal_error_abort()


On 26/11/14 20:09, Alexandros Frantzis wrote:
> Hi all,
>
> in a recent review the subject of how to deal with precondition failures
> in the client API came up again. In discussions we had yesterday the
> consensus was that we should abort the process. This has the benefit of
> catching the error as early as possible, making debugging much easier.
>
> The drawback versus a more forgiving approach is that and some programs
> may not be able to deal with such abrupt failures well. However,
> programs that absolutely need to do some critical cleanup should handle
> such failures anyway, regardless of whether they come from the Mir
> client library or not.
>
> This is not a new discussion, but we hadn't explicitly stated any
> guidelines before, so we had not been actively encouraging such handling
> of precondition failures during reviews.
>
> So, the proposed guideline is: abort on precondition failures in client
> API functions. This can be best achieved with a mir_assert() or similar
> function/macro that will be always on regardless of the build type.
>
> Thoughts?
>
> Thanks,
> Alexandros
>