Note, I am not implying that OCaml does the conversion of an unhandled
exception to a call to abort(). Rather, I can show you that this happens
down in the throw handler in libstdc++. I can produce this error in a pure
C++ program without any OCaml around to do anything.

What puzzles me, and at the same time, inspires admiration for the OCaml
team, is that they somehow manage to neutralize these ascending escapes.
Were it not for that, there might be a lot of unhandled cleanup in the OCaml
code that gets bypassed.

No the correct way to handle this situation is down close to the calls into
the throwing C++ code, and not far up the dynamic stack chain.

It appears from reading the runtime sources on OCaml that they are doing
some signal magic. I just was taken by surprise that this happened in a
foreign function call as well. That seems like unnecessary overhead most of
the time, but probably keeps dummies from getting burned to badly....

David McClain
Senior Corporate Scientist
Avisere, Inc.

+1.520.390.7738 (USA)
david.mcclain@avisere.com



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners