Re: Current best practice for C++ exception handling

[Gaspard Bucher <gaspard@...>]

Thanks for the reply. I just adapted Dub to wrap the calls with try/catch blocks (which can be specialized for library specific exceptions) and it works fine. All calls to lua use pcall so the C++ to Lua interface should be safe.

As for the remark on swig: this project has many qualities but it two main disadvantages over Dub:

* you have to write receipts

* you cannot parse the inline C++ documentation to generate the docs

* it's a compiled piece of code (not that easy to adapt)

* you have to learn yet another language just for the bindings

The idea behind dub is that you parse your C++ code with Doxygen (giving you html documentation) and feed the xml output to get the bindings. No receipt, no configuration.

Generating the bindings for OpenCV is just a couple of lines of ruby (50) to create 4 classes and 240 enums and 171 methods. Maybe dub is not perfect, but if you need to get bindings fast for a couple of classes, it could be easier and if the code generation proves to be really less good the swig, then let's use dub to create swig receipts !

Since we are on the subject, is there a way to have multiple values for lua's cpath like $PATH (/usr/local/lib:.:~/classes) ?

Gaspard

On Fri, Mar 12, 2010 at 12:09 PM, M Joonas Pihlaja <jpihlaja@cc.helsinki.fi> wrote:

On Fri, 12 Mar 2010, Gaspard Bucher wrote:

> Anyway, my current bindings for OpenCV are working except for C++
> exception handling. I have two options here:
>
> A. adapt "Dub" to wrap all calls in a try .. catch block and use
> lua_error to push "what()" on the stack

This is what you need to do.  You also may need to protect calls to
the Lua API with lua_pcall / lua_cpcall if you're relying on RAII or
other non-POD objects on the stack, since otherwise Lua's longjmp will
just whizz past your stack frames and not unwind correctly.  The
safest approach is one where you keep a strict separation between
contexts where Lua may raise an error and ones where C++ code may
throw an exception, and never let the two overlap.

Indeed, the one time when I've had to integrate C++ code with Lua I
ended up writing a pure C interface to the C++ code first and
converted all C++ exceptions using try/catch/what() at the C <-> C++
boundary.  After that it was smooth sailing to bind the Lua code to
the C API.

You may opt to target Lua VMs which are compiled to use your

compiler's C++ exceptions instead of setjmp/longjmp error handling,
but I don't know very much about this so hopefully others can chime in
on how to make this option work best.  Looking at the code in
luaconf.h, it looks like Lua does not extract any sensible error
object from exceptions which it didn't raise itself.  Based on a quick
test it looks like if Lua pcalls a lua_CFunction which throws a C++
exception then the error object is then the lua_CFunction itself,
regardless of what the exception is.

Cheers,

Joonas