On SL5, onrec01:MAUS/.maus_trunk where it fails

[miceonrec01] .maus_trunk > python ./test_converter_debug.py
terminate called after throwing an instance of 'MAUS::Exception'
  what():  In branch daq_event_type
Missing required branch daq_event_type converting json->cpp at ValueItem::_SetCppChild
Aborted
[miceonrec01] .maus_trunk >

common_cpp/JsonCppProcessors/ObjectProcessor-inl.hh:196

On SL6, a python try/catch does indeed correctly catch the throw.
Same script on onrec03:MAUS/.maus_trunk

[mice@miceonrec03 .maus_trunk]$ python ./test_converter_debug.py
Exception  In branch daq_event_type
Missing required branch daq_event_type converting json->cpp at ValueItem::_SetCppChild
.
----------------------------------------------------------------------
Ran 1 test in 0.004s

OK
[mice@miceonrec03 .maus_trunk]$

Here is a thing, I think this caused a similar problem in the past, but yours is not necessarily the same.

• Blah.so is built by linking to Exception.o, generating symbol Blah::Exception
• Bleurgh.so is built by linking to Exception.o, generating symbol Bleurgh::Exception
• If we throw from Blah.so and try to catch in Bleurgh.so; we throw a Blah::Exception and try to catch a Bleurgh::Exception. gcc RTTI thinks these are two different types and the catch fails.

Probably there is a fix using some combination of extern keyword and forward declaration, or hacking the build scripts so that MAUS::Exception is only built in libMausCpp.so, or something. I spent a morning fiddling trying to figure it out but didn't get the answer. In the end I resigned myself to catch std::exception (built in libc.so and nowhere else).

In which case, the patch would be

=== modified file 'src/py_cpp/PyConverter.cc'
--- src/py_cpp/PyConverter.cc    2015-07-10 11:43:26 +0000
+++ src/py_cpp/PyConverter.cc    2015-07-20 08:45:24 +0000
@@ -37,6 +37,10 @@
       if (data_out != NULL && py_data_out == NULL)
           throw; // memory was lost, raise it up...
       PyErr_SetString(PyExc_ValueError, (&exc)->what());
+  } catch (std::exception& exc) {
+      if (data_out != NULL && py_data_out == NULL)
+          throw; // memory was lost, raise it up...
+      PyErr_SetString(PyExc_ValueError, (&exc)->what());
   }
   return py_data_out;
 }

I pushed the patch, not sure if this will make a difference (I noticed the third_party build passed last night for example...)

How much do we care about SL5 anyway? We already cannot build the unpacker properly on SL5...