Re: [Caml-list] C++ Throws

["David McClain" <dmcclain1@mindspring.com>]

Okay Skaller... (John, isn't it?) Smarty pants... you may be very correct
about most of this, but I can show you that an unhandled throw is being
turned into a call to abort() from which there is no recovery.

I do find it amazing that C++ would be dumb enough to try to scaffold raw
stack frames, instead of using some kind of dynamic link pointers to reach
each frame C++. How in the world would any kind of cross-language
interoperability ever function if this were the case. Mind you I'm not
disputing your estimate here, it's just that I find it a bit incredulous.

But whatever, at least with pseudo-functional closures I can handle this
problem the way that seems most natural, and down at the module level where
it probably belongs, even if it is more expensive in code and runtime. What
matters is programmer productivity and being able to prevent the application
from aborting just because of an indexing error. This is an interactive
application and abrupt aborts aren't very pleasant for the user, nor are
they necessary.

- DM

----- Original Message ----- 
From: "skaller" <skaller@users.sourceforge.net>
To: "David McClain" <dmcclain1@mindspring.com>
Cc: "Brian Hurt" <bhurt@spnz.org>; "caml-list" <caml-list@inria.fr>
Sent: Friday, August 27, 2004 18:40
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
>


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