[bind10-dev] proposal: catching exceptions in run_unittests.cc:main()

[JINMEI Tatuya / 神明達哉]

I have a minor extension proposal to our C++ unittests: catch standard
exceptions thrown (and uncaught) in the test and print its type and
what().

Specifically, instead of just:

    return (RUN_ALL_TESTS());

do this:

    int ret = 0;
    try {
        ret = RUN_ALL_TESTS();
    } catch (const std::exception& ex) {
        std::cerr << "An exception of class '" << typeid(ex).name()
                  << "' was thrown\n";
        std::cerr << " what(): " << ex.what() << std::endl;
        throw;
    }
    return (ret);

This is essentially what g++ does internally, and after switching to
clang++ (I'm mainly using clang++ for daily development because it's
much faster than g++) I found it's very g++ specific.  The SunStudio
C++ compiler doesn't seem to print the information of uncaught
exceptions before aborting either.

I like the g++ behavior because it helps identify what's wrong when a
test triggers an exception (unexpectedly, of course).  In some cases
which exception is thrown is quite obvious from the test name, but I
often need to add code like above temporarily or run the test from
debugger.  With the above code I can save time for the extra steps.
It will also be helpful when an exception is thrown on a buildbot box.

Possible concerns are:
 - we need to write this hook for any new run_unittests.cc's (after
   doing this for all existing ones).  I personally think it's okay
   because we don't need to create a new test main() so often
   (basically we only need a new one for a new module), and these
   files are mostly identical and we can easily use an existing one as
   a template.  Or, if this overhead is considered substantial, we
   could introduce a common library and call it from all tests.

 - typeid(type).name() may return mangled name, e.g. St13runtime_error
   instead of std::runtime_error, in which case the result would be a
   bit unreadable.  And this is the case for g++, and in this sense
   this approach is a degradation for it (with the g++'s default
   behavior we can see the demangled type name).  In practice, I think
   it's okay, too, and if we worry about the degradation for g++ we
   could selectively disable this hook for g++ (although I'd prefer
   simplicity and use the same code for all compilers), or we could
   add a filter to demangle the name (although I personally think it's
   too much for the purpose here).

Does anyone have an opinion/objection/better idea about this issue?

---
JINMEI, Tatuya