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
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
