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

[Christian Engwer]

On Fri, Oct 30, 2015 at 04:25:52PM +0100, Jorrit Fahlke wrote:
> Am Thu, 29. Oct 2015, 16:17:37 +0100 schrieb Christian Engwer:
> > Date: Thu, 29 Oct 2015 16:17:37 +0100
> > From: Christian Engwer <christian.engwer at uni-muenster.de>
> > To: Carsten Gräser <graeser at mi.fu-berlin.de>
> > Cc: dune-devel at dune-project.org
> > Subject: Re: [Dune-devel] [Dune-Commit] [Commit] dune-istl - 23d94ff:
> >  [tests] Catch Dune exceptions to ease identifying problems.
> > 
> > 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.
> 
> I guess the original reason for DUNE_THROW has been made obsolete (largely) by
> the introduction of to_string() in C++11.  I'd still keep it around, however;
> almost all dune code uses it and I don't see a good enough reason to change
> it.

I don't think the to_string a good alternative. We currently don't
implement it for our classes and the << operator is imho more convinient.

> Also, I know of some modules from Mario's group that redefine DUNE_THROW to
> include source location information, such things would be made harder if we
> abandon DUNE_THROW.

A couple of things can be achieved by the exception hook, but sure,
this does not cover all use cases.

Christian