Error handlers

[jedbrown]

This issue applies to other components as well, but I raised the issue on the MOAB list.

... it occurred to me that MOAB is obnoxiously difficult to debug. This is largely due to the fact that there is no obvious point to attach a debugger to see when an error first occurs. Instead, user code gets a helpful MB_FAILURE, and *my* error handler lets me easily have the debugger at this point. But finding the first place that the error occurs is really slow because I have to deal with it one stack frame at a time, either by stepping or bisecting at each frame. (GDB's new "reverse-debugging" can help, but it's finicky.) In contrast, when PETSc reports an error, I get a full stack trace (without the debugger) and I can immediately have a debugger on the line where the error first occurred (literally 1-5 seconds from "look, there's an error" to a debugger on the relevant line, even in parallel).

Having MOAB print it's own stack trace would take significant work, but allowing a user-defined error handler is simple (it would touch a lot of code, but not in an interesting way) and would help a lot. The main difficulty is that MBErrorCode is also used to return non-error conditions, therefore the error handler cannot just dump core or attach debuggers, it needs to first decide whether the error was intentional.

Jason's response:

Actually, keeping a stack trace could be done with about the same amount of work as supporting custom error handlers (or even making MOAB have a common error handler in which one can set a break point.) Any of these would require changing a lot of code in MOAB (in a fairly trivial way.) The largest issue with maintaining a stack trace is the runtime penalty for code within MOAB when some internal error code can be handled (e.g. we might expect to get MB_TAG_NOT_FOUND.)