Are LLVM "fatal errors" really fatal? - error-handling

Question

I'm wondering if LLVM fatal errors are really "fatal" - ie. they invalidate the entire state of the system and are not recoverable.
For example (I'm using the llvm-c interface), the default behavior of the following code:
LLVMMemoryBufferRef mb = LLVMCreateMemoryBufferWithMemoryRange(somedata, data_length, "test", 0);
LLVMModuleRef module;
if (LLVMParseBitcode2(mb, &module) != 0) {
fprintf(stderr, "could not parse module bitcode");
}
is that if the pointer somedata points to invalid bitcode, the fprintf is never executed, but instead the entire process aborts with its own fatal error message on stderr.
However, there is supposedly an interface to catch such errors: LLVMFatalErrorHandler. However, after installing an error handler, the process still just aborts without calling the error handler.
The documentation in LLVM is very poor overall, and the C interface is barely documented at all. But it seems like super-fragile design to have the entire process abort in a mandatory way if some bitcode is corrupt!
So, I'm wondering if "fatal" here implies, as usual - that if such an error occurs, we may not recover and continue using the library (for example trying some different bitcode or repairing the old one, for example), or if it is not really a "fatal" error and we can have the FatalErrorHandler or some other means of catching and notify, or take other remediating actions, and continue the program.

Answer 1

Ok, after reading through the LLVM source for 10+ hours and enlisting the help of a friendly LLVM dev, the answer here is that this is not in fact a fatal error, after all!
The functions called above in the C interface are deprecated and should have been removed; LLVM used to have a notion of "global context", and that was removed years ago. The correct way to do this - so that this error can be caught and handled without aborting the process - is to use the LLVMDiagnosticInfo interface after creating an LLVMContext instance and using the context-specific bitcode reader functions:
void llvmDiagnosticHandler(LLVMDiagnosticInfoRef dir, void *p) {
fprintf(stderr, "LLVM Diagnostic: %s\n", LLVMGetDiagInfoDescription(dir));
}
...
LLVMContextRef llvmCtx = LLVMContextCreate();
LLVMContextSetDiagnosticHandler(llvmCtx, llvmDiagnosticHandler, NULL);
LLVMMemoryBufferRef mb = LLVMCreateMemoryBufferWithMemoryRange(somedata, data_length, "test", 0);
LLVMModuleRef module;
if (LLVMGetBitcodeModuleInContext2(llvmCtx, mb, &module) != 0) {
fprintf(stderr, "could not parse module bitcode");
}
The LLVMDiagnosticInfo also carries with it a "severity" code that indicates the seriousness of the error (sometimes mere warnings or perfomance hints are returned). Also, as I suspected, it is not the case that failing to parse bitcode invalidates the library or context state.
The code that was aborting with the cruddy error message was just a stop-gap to let legacy apps which still called the old API functions work - it set up a context and a minimal error handler which behaves in this way.