I'd like to revisit a previous the root-talk thread on exception handling. In that thread one root user pointed out that any exception thrown by a compiled function will cause root to terminate. I have just run into the same problem and I agree that this is an unusually annoying feature. At the time of the previous thread, there were two responses, one from Fons and the other from Masa as follows: 1) Fons added some code to TSystem::Run() which attempted to catch exceptions at that level and restart the application. This doesn't work for compiled functions called by the interpreter. I believe that the reason it doesn't work is that CINT is written/compiled in C, so the exceptions can't propagate up the stack past CINT. 2) Masa stated that problems implicit in the C++ definition make it impossible to catch exceptions from compiled functions in the interpreter. I think that in fact what is needed is not the handling of the exceptions per se, but rather some stop-gap to prevent root from terminating if an exception is thrown by a compiled function being interpreted. I believe that this is possible and that it can be implemented in one of two ways. The most trivial way would be to put an additional layer between cint and the compiled function, as follows: Right now Cint call compiled C++ functions in int G__call_cppfunc(...) { --- stuff snipped --- (*cppfun)(...); --- stuff snipped } The additional C++ layer could be added as follows: int G__call_cppfunc(...) { --- stuff snipped --- if (G__cpp_stopgap(cppfun, ...)) { ---- function failed... stop interpreting --- } --- stuff snipped } where G__cpp_stopgap must be a C++ function like: extern "C" { typedef int (cppwrap)(G__value*, char*, G__param*, int); int G__cpp_stopgap(cppwrap* cppfunc, G__value* a, char* b, G__param* c, int d) { try { (*cppfunc)(a, b, c, d); return 0; } catch (...) { return 1; } } } A more elegant way of handling the exceptions would be to put the try...catch code into the cint wrappers themselves based on the throw() clause of the function definition.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:42 MET