Exceptions in Lablgtk callbacks

Question

In Lablgtk, whenever there is an exception in a callback, the exception is automatically caught and an error message is printed in the console, such as:

(prog:12345) LablGTK-CRITICAL **: gtk_tree_model_foreach_func: 
    callback raised an exception

This gives no stack trace and no details about the exception, and because it is caught I cannot retrieve this information myself.

Can I enable more detailed logging information for this case? Or prevent the exception from being caught automatically?

I guess you can catch the exception yourself and add as much logging as you need. — Thomash, Mar 12 '15 at 20:31
For more detailed information, you'll need to compile your binary in debug mode, and use debuggers like gdb to see "where" and why the function breaks. — Joel, Mar 13 '15 at 18:24

score 1 · Accepted Answer · answered Mar 16 '15 at 14:47

1

I guess the best way to do so is to catch your exception manually and handle it yourself.

let callback_print_exn f () =
 try f () with
 e -> my_exn_printer e

Assuming val my_exn_printer : exn -> unit is your custom exception printer, you can simply print your callbacks exceptions by replacing ~callback:f by ~callback:(callback_print_exn f) in your code.

Of course, you can also with that method send that exception to another thread, register a "callback id" that would be passed along with your exception...

About the stack trace, I'm not sure you can retrieve it easily. As it's launched as a callback, you probably want to know the signal used and that can be stored in your callback handler.

answered Mar 16 '15 at 14:47

PatJ

5,996
1
31
37

I guess the answer here is indeed "there is no better way to do it", as this [unanswered lablgtk-list message from 2008](https://lists.ocamlcore.org/pipermail/lablgtk-list/2008-February/001552.html) seems to indicate. Too bad there is not a "debug mode" where exceptions are not caught by default. It would probably require recompiling lablgtk to modify this behavior. – anol Mar 17 '15 at 12:55
@anol Probably, the thing is, as the callbacks may be called at any time in the code, the exceptions may be raised anywhere and that's something you really don't want to happen. – PatJ Mar 17 '15 at 13:59

score 1 · Answer 2 · edited May 23 '17 at 11:45

I had another similar issue, but this time it was harder to find where to put the calls to intercept the exception.

Fortunately, this time there was a very specific error message coming from the Glib C code:

GLib-CRITICAL **: Source ID ... was not found when attempting to remove it`

Stack Overflow + grep led me to the actual C function, but I could not find which of the several Lablgtk functions bound to this code was the culprit.

So I downloaded the Glib source, added an explicit segmentation fault to the code, compiled it and used LD_LIBRARY_PATH to force my modified Glib version to be loaded.

Then I ran the OCaml binary with gdb, and I got my stack trace, with the precise line number where the Lablgtk function was being called. And from there it was a quick 3-line patch.

Hacks like this one (which was still faster than trying to find where to intercept the call) could be avoided by having a "strict mode" preventing exceptions from being automatically caught. I still believe such a switch should be available for Lablgtk users, and hope it will eventually be available.

Exceptions in Lablgtk callbacks

2 Answers2