Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCaml handler for uncaught exception #5941

Closed
vicuna opened this issue Mar 11, 2013 · 4 comments
Closed

OCaml handler for uncaught exception #5941

vicuna opened this issue Mar 11, 2013 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Mar 11, 2013

Original bug ID: 5941
Reporter: @diml
Assigned to: @diml
Status: closed (set by @xavierleroy on 2015-12-11T18:26:37Z)
Resolution: fixed
Priority: normal
Severity: feature
Version: 4.01.0+dev
Fixed in version: 4.02.0+dev
Category: runtime system and C interface
Tags: patch
Related to: #5040
Monitored by: @gasche @jmeber

Bug description

The attached patch allows the user to register an OCaml function to handle uncaught exceptions. The default handler does the same as the C function except that it calls [Printexc.to_string], which uses user-defined exception printers.

The new function is:

Printexc.set_uncaught_exception_handler: (exn -> raw_backtrace option -> unit) -> unit

The backtrace is [None] when the debugger is active.

File attachments

@vicuna
Copy link
Author

vicuna commented Mar 11, 2013

Comment author: @gasche

I'm a bit confused by your caml_callback2 invokation: the second parameter is Val_bool(DEBUGGER_IN_USE), while the OCaml type expects an argument of type (raw_backtrace option).

Otherwise I'm impressed by the speed at which you made use of the new raw_backtrace type :-)

Could you explain what the debugger test is there for? I am not familiar with its interaction with the backtrace code.

When developing the raw_backtrace interface, Jacques-Henri Jourdan and I wondered if we should expose whether the backtrace was correctly recorded or not directly in Printexc.get_raw_backtrace, by having it return a raw_backtrace option to indicate validity (instead of embedding failure in the type by just returning empty allocated space). We eventually decided to follow what had been done for the rest of the interface, that has explicit no representation of failure to collect traces (we weren't sure we could make sure that the backtrace is valid in all cases), but if you have a different opinion I'd like to know: it's still possible to change the interface in trunk.

@vicuna
Copy link
Author

vicuna commented Mar 12, 2013

Comment author: @diml

I'm a bit confused by your caml_callback2 invokation: the second parameter is Val_bool(DEBUGGER_IN_USE), while the OCaml type expects an argument of type (raw_backtrace option).

caml_callback2 is applied on Printexc.handle_uncaught_exception, which is a wrapper around the user provided function.

Otherwise I'm impressed by the speed at which you made use of the new raw_backtrace type :-)

;-)

Could you explain what the debugger test is there for? I am not familiar with its interaction with the backtrace code.

I'm not 100% sure, but looking at startup.c the debugger interactive loop is called before caml_fatal_uncaught_exception, so that maybe related (the test was already there). Actually I don't think the latter will ever be called when using ocamldebug.

When developing the raw_backtrace interface, Jacques-Henri Jourdan and I wondered if we should expose whether the backtrace was correctly recorded or not directly in Printexc.get_raw_backtrace, by having it return a raw_backtrace option to indicate validity (instead of embedding failure in the type by just returning empty allocated space). We eventually decided to follow what had been done for the rest of the interface, that has explicit no representation of failure to collect traces (we weren't sure we could make sure that the backtrace is valid in all cases), but if you have a different opinion I'd like to know: it's still possible to change the interface in trunk.

I used an option because of this debugger test, but I should probably follow the same convention as for get_raw_backtrace. I have no strong opinion about whether it should be an option or not, but if get_raw_backtrace cannot be made to return None exactly when the backtrace is invalid I think it is better to just return an empty one.

@vicuna
Copy link
Author

vicuna commented Apr 16, 2014

Comment author: @diml

I worked a bit more on the patch and posted the final version on github for more review. If there is no objection I'll commit it.

@vicuna
Copy link
Author

vicuna commented Apr 18, 2014

Comment author: @diml

Committed, revision 14643.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant