[Dune-devel] [Dune-Commit] [Commit] dune-istl - 23d94ff: [tests] Catch Dune exceptions to ease identifying problems.

[Christian Engwer]

On Thu, Oct 29, 2015 at 04:10:34PM +0100, Carsten Gräser wrote:
> Hi,
> 
> Am 23.10.2015 um 08:50 schrieb Christian Engwer:
> >> I like the idea of making Dune::Exception a std::exception. But we have
> >> our Dune::Exception::what() returning a std::string& and not a char*.
> >> Can we easily change this without braking all code using our exceptions?
> > 
> > that should not the the big deal, as users never use the what
> > explicitly, but just to output it.
> > 
> >> And would we get rid of DUNE_THROW? That would be an argument for me to
> >> break code.
> > 
> > No we don't get of DUNE_THROW. Actually you don't _have_ to use it,
> > but composing the error message is horrible otherwise. We can't (or at
> > least didn't succeed) dervive from std::stringstream, but in order to
> > allow to use something like
> > 
> > throw myexception() << "Hallo " << 123;
> > 
> > we'd have to derive the exception class fomr some type of ostream,
> > which doesn't work, as ostream has a deleted copy constructor. To
> > circuvent these problems we came up with the idea of first writing to
> > a stringstream and the copying the string to the exception class.
> it should be easy to work around this by storing a stream in the
> exception and forwarding operator<<. But I doubt we can get the
> result of THROWSPEC without using a macro.

that is the other issue. If you want to include __FILE__ tec, you have
to use the preprocessor. Regarding the ostream, yes we can forward
oeprator <<, but then (a) none of the usual output operators for
other classes will match for an exception and (b) we still have the
copy issue, as the exception contains the ostream and the exception
has to be cpied, the ostream has to be copied as well.

Christian