> On Feb 6, 2026, at 06:28, [email protected] wrote: > > [russ] Yeah I thought that the binding interfaces would need to remain as > C-Linkage but can still be C++ code underneath. >
No, SWIG is and always has been primarily a C++ binding library and GncOptions creates a C++ swig file with C++ linkage, but exceptions require special treatment, see https://www.swig.org/Doc4.0/SWIGDocumentation.html#SWIGPlus_exception_specifications and https://www.swig.org/Doc4.0/SWIGDocumentation.html#SWIGPlus_catches and the Guile module doesn’t implement exceptions. >> Note that >> loc_func1 still has to check ext.m_except_data.exception_hit and if it’s >> true do >> something with the rest. I suspect that that something will turn out to be >> sufficiently not generic that having the template won’t really save much over >> just catching the exception in the implementation function or writing a C >> wrapper that handles exceptions in a way that’s appropriate for the execution >> context at hand. > > the fence is in func1(), but the implementation logic is in loc_func1(). No, loc_func1 is a wrapper that fences func1; the implementation is ExceptFence::forward_to. > I agree that if we mandate a giant catch-all at the top of all the C-APIs > when implementing that might work for catching everything but in my > experience its tricky to get right and error prone. E.g. if we instantiate an > object before the try, those constructors can throw unprotected. FTR I think it’s better to crash out on an unhandled exception than to implement a global exception handler because the further away from the throw that the exception is caught the harder it is to discover the context of the exception whereas an uncaught exception crashes at the throw site making it easy for the user to get a stack trace. > >> >> BTW, “m_exception_error_integer” is a problem because it implies that that’s >> a single value used for all cases and it’s not hard at all to think of cases >> where >> different values would be needed for signaling an error. > > [russ] in the implementation of ExceptFence, the constructor can take any > integer value and use that as the error value for integer return types. That isn’t illustrated in your example. > Void functions are tougher. Caught exceptions currently just return and leave > an unknown state behind without any side effects. If there was some > notification possible that would be nice. There’s always notification possible: PERR() will write whatever you want into the trace file. A void function exists to perform a side-effect and the side effect can be made to reflect the exception. That’s obviously difficult at best with a generic exception fence. > > Once nice thing of having the fencing in a single class is if you suspect an > unhandled exception e.g. in a void C-API func, it’s a single breakpoint in > the code. One never needs to suspect an unhandled exception: The program crashes with SIGABRT and __cxa_throw is a better single breakpoint. Once the exception is caught it’s too late to find out the cause of the exception. Regards, John Ralls
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
