Subject: How to deal with client API precondition failures

From: Alexandros Frantzis <[email-masked]>
Date: Wed, 26 Nov 2014 14:09:29 +0200

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

---

From: Alan Griffiths <[email-masked]>
Date: Wed, 26 Nov 2014 17:14:02 +0000

> function/macro that will be always on regardless of the build type.

Firstly we ought to be clear that a precondition failure is the calling
code failing to meet its requirements. Not about unexpected runtime
conditions (like the server socket suddenly closing). If the calling
code can't ensure the condition is met then it isn't a precondition for
the call.

Secondly, while not wishing to disturb the "consensus" I think we should
make no *promise* about what to do.

We should make any cheap precondition tests (without committing to doing
so). However, some preconditions are impossible to validate cheaply.
(E.g. someone passes a pointer to a random piece of memory where we were
expecting something meaningful.)

If & when we detect a precondition failure then the question arises what
to do and I agree that abort is the right approach. Failing quickly and
loudly is appropriate as anything else could lead to an error being
overlooked during development and failing in a production environment.

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 27 Nov 2014 09:46:54 +0800

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()

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 27 Nov 2014 17:09:39 +1100

I have nothing much to add to this, besides my +1. Cheap precondition 
tests should abort.