Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] C++ Throws
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] C++ Throws
On Sat, 2004-08-28 at 10:11, David McClain wrote:
> Hi Brian,
> 
> Yes, that technique is the one that I said previously works just fine. I was
> hoping for a higher level generic handler, instead of wrapping each
> individual lib call with this try-catch block.
> 
> I have been doing C++ to OCaml for years now with no difficulty. The catch
> here is that OCaml appears to be interposing between the established higher
> level catch handlers and the source of the throw exceptions. It appears to
> insist on not allowing any lower dynamic exceptions to propagate above its
> interface with a C call.

No, I doubt that. What's actually happening is quite the opposite.
C++ stack unwinding involves synchonously destroying stack
objects and NOT returning control until the handler is reached.

But you've stuck some Ocaml stack frames in the way.
Far from Ocaml 'grabbing control', it isn't doing anything.
Ocaml isn't ever getting control -- C++ knows nothing
and just keeps going -- it doesn't execute the
'return' instruction for the callers program counter,
it throws it away.

Actually it's more complex than that -- EH has two jobs:
(a) locate the handler
(b) unwind the stack up to it then give it control

It is allowed to unwind the stack whilst looking
for the handler.

It is also allowed to locate the handler FIRST,
and THEN unwind. In particular if there is NO handler,
it is allowed to core dump on the spot without unwinding
anything -- the reason being that you then get a dump
which actually includes debugging information :)

Either way it is C++ which will either abort()
because it can't find a handler, or corrupt
your system and lock up or crash, if it it actually
get stuck misinterpreting the Ocaml stack frames
either during unwinding or trying to find
the stack frames .. don't even count on abort()
being called.

I think it is possible to write generic handler,
but only if you have detailed implemention details
from you compiler vendor on how EH is implemented
on your platform :(


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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