On Fri, Oct 22, 2010 at 12:27 AM, bradley.meck <bradley.m...@gmail.com>wrote:
> 1) I am not a v8 dev but here are my thoughts. Throwing in normal C++ > would be rather hard to recover from if you wish to continue in the > same code path (you could do nested try catches I guess). If you were > to provide bindings to a non-c++ language this would be extremely odd > to work around. > Consider a case like: v8 client binds JS to C code, which indirectly calls a JS method which is implemented in C++. That final C++ throws, propagating the exception across library boundaries (from the C++ callback impl into the v8 engine). Assuming v8 doesn't catch the exception when the C++ layer leaks it out (and v8 can't really know what to catch because C++ allows us to throw nearly anything (e.g. throw "hi, world")), the exception will then bubble up into the C API, which is an absolute no-no because the C API has no way of cleaning up in the face of exceptions (in C we must reach the calls to our cleanup routines, since they won't be called automatically when an exception forces us out of scope). Herb Sutter wrote an article (or an "item" in one of his books, i don't remember) which gives the reasons why it is poor practice to let exceptions cross library boundaries. i don't remember all of the details (it's been a good 5 years since i read it), but the above description should give some idea of what's involved. In summary: - v8 can't really know what it should/should not catch. Though the STL has a standard exception hierarchy, there is no language-standard hierarchy, and thus clients may throw whatever they want to. - Even if v8 could catch (e.g. std::exceptions), allowing our exceptions to cross library boundaries into v8 is (according to Herb Sutter, at least, and i believe him on this point), poor practice. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users
