A general rule is that exception do not get out of c4 API, such as c4log_xyz. However, in error::_throw
void error::_throw(unsigned skipFrames) {
if (sWarnOnError && !isUnremarkable()) {
if (sNotableExceptionHook)
sNotableExceptionHook();
......
The exception hook may go out of C4.
I encountered this problem by this innocent call of c4
if (!c4log_writeToBinaryFile({kC4LogVerbose, slice(path), 16*1024, 1, false},
&error))
Supposedly, exception thrown from inside the c4 code should be caught and be reflected in error. However, because of the above, the exception hook calls into c4log_ again. This recursive calls of c4_xyz's caused the app hang because of the plain mutex, as opposed to recursive_mutex.
A general rule is that exception do not get out of c4 API, such as c4log_xyz. However, in error::_throw
void error::_throw(unsigned skipFrames) {
if (sWarnOnError && !isUnremarkable()) {
if (sNotableExceptionHook)
sNotableExceptionHook();
......
The exception hook may go out of C4.
I encountered this problem by this innocent call of c4
if (!c4log_writeToBinaryFile({kC4LogVerbose, slice(path), 16*1024, 1, false},
&error))
Supposedly, exception thrown from inside the c4 code should be caught and be reflected in error. However, because of the above, the exception hook calls into c4log_ again. This recursive calls of c4_xyz's caused the app hang because of the plain mutex, as opposed to recursive_mutex.