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

[Carsten Gräser]

Am 29.10.2015 um 16:17 schrieb 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.
I don't believe (a) and (b). (a) can be solved by a templated
'operator <<' and to avoid (b) you just have to avoid the
copy of the stream member and forward the content of the other
exception into a newly created empty stream member. See attachment
patch for a working example. Notice that this is incomplete, because
it does not implement assignment and setting of flags, width, precision.

I don't propose to merge this. I just want outline that (a)
and (b) should not be the reason to keep the macro.

Best,
Carsten







-------------- next part --------------
A non-text attachment was scrubbed...
Name: streamlike-exception.patch
Type: text/x-patch
Size: 2028 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20151109/7795451e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20151109/7795451e/attachment.sig>