Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2004-08-28 (09:24)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] C++ Throws
On Sat, 2004-08-28 at 18:17, Xavier Leroy wrote:

> There are indeed two "schools" of exception handling: one that unwind
> stack frames one by one until an exception handler is found, and one
> that maintains at run-time a chaining between exception handling
> blocks on the stack, so that no stack searching is necessary when an
> exception is thrown.
> The first school is exemplified by C++, Modula-3, Java and C#; the
> second school by Lisp, Caml and to some extent Prolog (if you view
> backtracking as a generalization of exception handling).

C++ is required by the ISO Standard
to unwind each frame to the handler, executing
destructors in FILO order. Ocaml doesn't need to do that,
it has a garbage collector which finalises blocks out of order.

> The two approaches have very different performance trade-offs.  To
> make things worse, many people from the first school are not even
> aware of the second approach.  So, as usual, there is no hope to see
> the world converge on a single exception mechanism.

As above -- for C++ it is tied up with the requirement
to execute destructors of stacked objects in a FIFO manner. 
Simply dropping back to the handler isn't an option.

So it isn't necessarily ignorance that will prevent
convergence -- there are distinct architectural models
to consider, in this finalisation in C++ must be
FILO in both normal and exceptional exits --
C++ code is allowed to rely on destructors executing
in reverse order to constructors. 

> >  How in the world would any kind of cross-language
> > interoperability ever function if this were the case. 

The C++ committee was only ever concerned with
C interoperability. Its not their job to consider
other languages, especially ones that do not
have ISO Standards backing them, where inter-committee
liason is impossible.

> For the reverse direction (Caml calling C++), I'm afraid the only
> solution is to use a C++ catch-all clause to turn C++ exceptions into
> Caml exceptions.

Which can't be done in a portable manner: since the catch-all
cannot have an associated static type, you can't actually
refer to the exception object in the handler.

Other languages -- Java and now Python -- have a top
level exception type from which all exceptions must
be derived. In C++, the type doesn't even have to
be polymorphic -- you can throw an int or string
if you want. Perhaps that's stupid but the reason
is compatibility with earlier C++ code which typically
threw int or char *.

John Skaller,
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: