You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 6, 2025. It is now read-only.
Akumuli terminates the process if a non-recoverable error occurs.
This might be ok for embedded C/C++ usage (libakumuli) or daemon (akumulid) applications.
But this usage is not suitable if libakumuli used from managed environments (JVM, .NET).
We overide the default aku_panic_handler_t with our custom implementation but libakumuli still terminates the process.
If panic occurs, our custom aku_panic_handler_t throws JVM Exception from JNI. But caller couldn't catch the exception because of the termination.
Is it possible to add an additonal logic to invoke_panic_handler so that library user decide if application should be crashed or not.
Beside this, caller might initialize the Akumuli so that all states will be cleared. If this new feature will be introduced, libakumuli might be recover the error and will be continue to run.
Hi,
Akumuli terminates the process if a non-recoverable error occurs.
This might be ok for embedded C/C++ usage (libakumuli) or daemon (akumulid) applications.
But this usage is not suitable if libakumuli used from managed environments (JVM, .NET).
We overide the default
aku_panic_handler_twith our custom implementation but libakumuli still terminates the process.If panic occurs, our custom
aku_panic_handler_tthrows JVM Exception from JNI. But caller couldn't catch the exception because of the termination.Is it possible to add an additonal logic to invoke_panic_handler so that library user decide if application should be crashed or not.
Beside this, caller might initialize the Akumuli so that all states will be cleared. If this new feature will be introduced, libakumuli might be recover the error and will be continue to run.