How to handle exceptions in test cases / example applications?

Recently @pipping, @joe and @smuething where discussing with be about how to handle exceptions in our tests. See:

• core/dune-istl@4c9e6cf4537152cf5f4f0b03254c91481b35d0d0
• dune-grid-howto!4 (merged)

Following Elias suggested I wanted to reduce the code to

} catch(std::exception& e){
  throw;
}

What do you think?

I really don't see the point of that catch clause. If that is all you do, just leaving it out will do the same thing...

I am fine with dropping the complete try / catch stuff which clutters the examples.

Asking my question the opposite way: Is there a reason to keep it at all?

Added discussion label

I like how the current clause prints a meaningful error message that I can read without having to fire up the debugger.

Recent versions of libgcc and libstdc++abi contain a version of std::terminate() that catches std::exception and prints an error message, so you don't need the debugger for that anymore.

On the other hand, there is still the issue that uncaught exceptions cause a very messy program shutdown - the compiler doesn't even have to guarantee stack unwinding, let alone execution of global finalizers (like destructors of singletons). Pretty much the only thing that's guaranteed (by the OS, basically) is that your memory will be released, your files closed and all of your streams flushed before that (but maybe only stdin, stdout and stderr). So if you have some other state that you need to clean up (like removing a semaphore or finalizing a pending asynchronous HDF5 write that shouldn't fail just because the iterative solver did not converge in your next iteration), you're probably SOL.

So I don't like the idea of teaching people that the way to reliable programs is to just let exceptions propagate...

@oliver.sander If the error message is all you're after, compiler support for that at least looks rather good:

#include <exception>

class C : public std::exception
{
  const char* what() const noexcept override {
    return "some random error";
  }
};

int
main()
{
  throw C();
}

% clang++ -std=c++14 -stdlib=libstdc++ foo.cc && ./a.out         
terminate called after throwing an instance of 'C'
  what():  some random error
zsh: abort      ./a.out
% clang++ -std=c++14 -stdlib=libc++ foo.cc && ./a.out
terminating with uncaught exception of type C: some random error
zsh: abort      ./a.out
% g++ -std=c++14 foo.cc && ./a.out         
terminate called after throwing an instance of 'C'
  what():  some random error
zsh: abort      ./a.out
% g++-libc++ -std=c++14 foo.cc && ./a.out 
terminating with uncaught exception of type C: some random error
zsh: abort      ./a.out
%

That’s with

% clang++ --version
clang version 3.8.0 (tags/RELEASE_380/rc2)
Target: x86_64-unknown-linux-gnu
Thread model: posix

% gcc --version
gcc (Debian 4.9.2-10) 4.9.2

I cannot personally test with icc.

Update: Longer version from a while back: https://gitlab.dune-project.org/snippets/14

@pipping Thanks, I didn't know that.

@smuething: Referring to

So if you have some other state that you need to clean up (like removing a semaphore or finalizing a pending asynchronous HDF5 write that shouldn't fail

I'm not sure what we're talking about here. This is not an issue in tests. So are we talking about user code then? If we have a user who deems HDF5 a suitable IO facility, he or she is the only one who knows what needs to be done to make sure his or her HDF5 files don't end up garbled. So he or she needs to put a catch in the right place, with the right handling. That's clear. Are you worried that if we remove catch clauses from tests that users will stop using exception handling in their own code, too?

@pipping Yes, that's not really an issue in tests, but I think we should keep the clauses in example code.

1. So what's about tests? Does anybody object to remove all try / catch from our tests and rely on a good™ C++ runtime library?
2. What about examples like in dune-grid-howto? Catch std::exception with an guaranteed output and let everything else fail?

If it's guaranteed that the runtime will print the message it's OK.

As far as I understood, this is not the case. But then I don't see the point in changing this. Even if it works in all cases, saving these one or two lines does not improve clarity to users. Currently you can clearly see what's going on. This changes if we rely on magic that isn't documented properly (i.e. in books/iso standard/cppreference) because it's non-standard.

There is no consensus. I'll revoke my merge request for dune-grid-howto and modify it to remove the catch for Dune::Excpetion which is already handled by std::exception.

mentioned in commit dune-istl@fb2ba881

mentioned in merge request dune-istl!39 (merged)

Adjust changed tests in dune-istl with dune-istl!39 (merged) and we are done.

Status changed to closed by commit dune-istl@fb2ba881

mentioned in commit dune-istl@dcade4ee