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

Documentation for Printexc.register_uncaught_exception_handler could be improved #6619

Closed
vicuna opened this issue Oct 19, 2014 · 8 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Oct 19, 2014

Original bug ID: 6619
Reporter: @johnwhitington
Assigned to: @diml
Status: closed (set by @xavierleroy on 2016-12-07T10:36:51Z)
Resolution: fixed
Priority: normal
Severity: text
Fixed in version: 4.02.2+dev / +rc1
Category: documentation
Monitored by: @diml @hcarty

Bug description

Currently, we have:


Printexc.set_uncaught_exception_handler fn registers fn as the handler for uncaught exceptions. The default handler prints the exception and backtrace on standard error output.

Note that when fn is called all the functions registered with at_exit have already been called. Because of this you must make sure any output channel fn writes on is flushed.

If fn raises an exception, it is ignored.

Following discussion on caml-list, I would suggest the final paragraph be replaced by something like:

"If an exception is raised inside the handler fn and remains uncaught, neither the default handler nor fn is called: the exception is ignored."

@vicuna
Copy link
Author

vicuna commented Oct 19, 2014

Comment author: @diml

Actually if [fn] raises an exception, the current code will print the original exception and backtrace and then the exception raised by [fn] with its backtrace.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2014

Comment author: @johnwhitington

Right, so if I have:

let f _ _ = raise Not_found

let _ = Printexc.set_uncaught_exception_handler f

let _ = failwith "foo"

I get

feast:~ john$ ./a.out
Fatal error: exception Failure("foo")
Fatal error in uncaught exception handler: exception Not_found

This seems like reasonable behaviour.

It doesn't work in the top level, though -- should it?:

    OCaml version 4.02.1

let f _ _ = raise Not_found;;

val f : 'a -> 'b -> 'c =

let _ = Printexc.set_uncaught_exception_handler f;;

  • : unit = ()

let _ = failwith "foo";;

Exception: Failure "foo".

@vicuna
Copy link
Author

vicuna commented Oct 20, 2014

Comment author: @diml

It doesn't work in the top level, though -- should it?

The exception is not uncaught, it is caught by the toplevel.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2014

Comment author: @diml

So, for the doc, how about this:

"If [fn] raises an exception, both the exceptions passed to [fn] and raised by [fn] will be printed with their respective backtraces."

@vicuna
Copy link
Author

vicuna commented Oct 20, 2014

Comment author: @johnwhitington

The exception is not uncaught, it is caught by the toplevel.

So in the example above, "Exception: Failure "foo" is printed by the top level, not by the default uncaught exception handler?

"If [fn] raises an exception, both the exceptions passed to [fn] and raised by [fn] will be printed with their respective backtraces."

Looks good.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2014

Comment author: @diml

So in the example above, "Exception: Failure "foo" is printed by the top level, not by the default uncaught exception handler?

Yes. I guess it could make sense to pass these exceptions to the uncaught exception handler.

In the meantime I'll add a comment about it.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2014

Comment author: @diml

As a side note, you can overwrite [Toploop.print_out_phrase] to get these exceptions.

@vicuna
Copy link
Author

vicuna commented Oct 20, 2014

Comment author: @diml

I commited a patch in trunk: 15560, and 4.02: 15561.

@vicuna vicuna closed this as completed Dec 7, 2016
@vicuna vicuna assigned ghost Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
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