CODEWITHSUNDEEP
exceptiongtkocamllablgtk
anol
anol

Reputation: 8953

Exceptions in Lablgtk callbacks

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?

Upvotes: 1

Views: 446

Answers (2)

anol
anol

Reputation: 8953

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.

Upvotes: 1

PatJ
PatJ

Reputation: 6144

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.

Upvotes: 1

Related Questions