caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: David McClain <dmcclain1@mindspring.com>,
	Brian Hurt <bhurt@spnz.org>, caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] C++ Throws
Date: 28 Aug 2004 19:24:08 +1000	[thread overview]
Message-ID: <1093685048.15255.1795.camel@pelican.wigram> (raw)
In-Reply-To: <20040828081743.GA1229@yquem.inria.fr>

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


  reply	other threads:[~2004-08-28  9:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-27 22:31 David McClain
2004-08-27 23:24 ` Brian Hurt
2004-08-28  0:11   ` David McClain
2004-08-28  1:40     ` skaller
2004-08-28  4:13       ` David McClain
2004-08-28  4:55         ` David Brown
2004-08-28  7:44           ` Ville-Pertti Keinonen
2004-08-28  7:48           ` Radu-Mihail Obada
2004-08-28  8:17         ` Xavier Leroy
2004-08-28  9:24           ` skaller [this message]
2004-08-28  9:31         ` skaller
2004-08-28  0:22   ` David McClain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1093685048.15255.1795.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=Xavier.Leroy@inria.fr \
    --cc=bhurt@spnz.org \
    --cc=caml-list@inria.fr \
    --cc=dmcclain1@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).