 |
lua-l archive |
|
|
||
|
"Glenn Maynard" <glenn@zewt.org> wrote in message 20061011235743.GW18958@zewt.org">news:20061011235743.GW18958@zewt.org...
How are people dealing with error handling in C++? setjmp doesn't get along with C++ destructors. luaconf.h has an alternate to use exceptions, but enabling exceptions bloats binaries massively (in VC, and even more in g++). Anyone found a good approach? In principle, I could move my Lua code into separate source files, enable exceptions for just those files, and make sure to catch all exceptions there. That would be a major hassle--dozens of bound classes, with Lua binding code at the end of each source file being bound, several build systems, and also a fair bit of inline Lua interfacing. (I also know no way to convince automake to send different compiler flags to different source files, short of building a library.) I'd sooner live with a memory leak on error than deal with that.
I'm not really aware of any good solution. A C++ project I worked on that used C++ exceptions found some very nasty errors (segfaults deep inside the bowels of g++). The bugs were hard to debug, seemingly non-deterministic, which was a mess. Apparently longjmp does not mess well with C++, and especially does not mesh well with c++ exceptions. So we ended up compiling lua as c++ using c++ exceptions in lua. The C++ standard says this:
18.7.4 The function signature longjmp(jmp_buf jbuf, int val) has more restricted behavior in this International Standard. If any automatic objects would be destroyed by a thrown exception transferring control to another (destination) point in the program, then a call to longjmp(jbuf, val) at the throw point that transfers control to the same (destination) point has undefined behavior.
So use of longjmp in most C++ programs has undefined results.