------=_Part_2076_1225168522.1406293111232
Content-Type: text/plain; charset=UTF-8

While implementing a unit test framework in modern C++, I found that I
wanted an interface for expecting exceptions like:

expect_exception<std::runtime_error>([&]{ do_work(); });

This lead me to wonder, "what if it were variadic?"

expect_exception<std::runtime_error, std::out_of_range>([&]{ do_other_work
(); });

Unfortunately, the implementation of this is not possible in C++11 or
C++1y, since param pack expansion in a catch is impossible. So, I am
interested in the group's thoughts on an extended syntax for param pack
expansion, similar to sizeof...(Ts), but for catch. It would work as
follows, continuing with my previous examples:

template <typename... Ts>
void expect_exception(std::function<void ()> const &f)
try
{ f(); }
catch...(Ts const &ex)
{ std::cerr << ex.what() << std::endl; }

Thanks for your time.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2076_1225168522.1406293111232
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While implementing a unit test framework in modern C++, I =
found that I wanted an interface for expecting exceptions like:<br><br><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">expect_exception=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">runtime_error</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;([&amp;]{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> do_work</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">});</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div><br>This lead me to =
wonder, "what if it were variadic?"<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify">expect_exception</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">runtime_error</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">out_=
of_range</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;([&amp;]{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> do_other_work</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">});</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><=
/code></div><br>Unfortunately, the implementation of this is not possible i=
n C++11 or C++1y, since param pack expansion in a catch is impossible. So, =
I am interested in the group's thoughts on an extended syntax for param pac=
k expansion, similar to sizeof...(Ts), but for catch. It would work as foll=
ows, continuing with my previous examples:<br><br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">typename</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Ts</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> expect_exception</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">function</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
onst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">try</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">catch</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">...(</span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">Ts</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
ex</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">cerr </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> ex</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">what</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span></div></code></div><br>Thanks for your time.<br>&nbsp=
;<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2076_1225168522.1406293111232--

.

On 25.07.2014 14:58, jeaye wrote:
> While implementing a unit test framework in modern C++, I found that I
> wanted an interface for expecting exceptions like:
>
> expect_exception<std::runtime_error>([&]{ do_work(); });
>
> This lead me to wonder, "what if it were variadic?"
>
> expect_exception<std::runtime_error, std::out_of_range>([&]{ do_other_work
> (); });
>
> Unfortunately, the implementation of this is not possible in C++11 or
> C++1y, since param pack expansion in a catch is impossible. So, I am
> interested in the group's thoughts on an extended syntax for param pack
> expansion, similar to sizeof...(Ts), but for catch. It would work as
> follows, continuing with my previous examples:
>
> template <typename... Ts>
> void expect_exception(std::function<void ()> const &f)
> try
> { f(); }
> catch...(Ts const &ex)
> { std::cerr << ex.what() << std::endl; }
>
> Thanks for your time.
>
>


You can for example catch all exceptions with catch(...) and rethrow
them in a templated function so I think there is no need for a language
feature.

#include <iostream>
#include <stdexcept>
#include <typeinfo>

template<class... E>
struct my_catch;

template<>
struct my_catch<>
{
     void operator()() {
         throw;
     }
};

template<class E0, class... E>
struct my_catch<E0, E...>
{
     void operator()() {
         try {
             throw;
         } catch (E0 const& ex) {
             std::cerr << ex.what() << "(" << typeid(ex).name() << ")"
<< std::endl;
         } catch (...) {
             my_catch<E...>{}();
         }
     }
};

int main() {
     try {
         throw std::runtime_error("Hello");
     } catch (...) {
         my_catch<std::runtime_error, std::logic_error>{}();
     }

     try {
         throw std::logic_error("World");
     } catch (...) {
         my_catch<std::runtime_error, std::logic_error>{}();
     }

     return 0;
}

(live example: http://coliru.stacked-crooked.com/a/7c7ecc14b976ed8a )

Jan Herrmann





--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2190_886840622.1406301983071
Content-Type: text/plain; charset=UTF-8



> You can for example catch all exceptions with catch(...) and rethrow
> them in a templated function so I think there is no need for a language
> feature.
>

I can implement sizeof...(Ts) entirely using constexpr function templates,
does that mean it shouldn't be a language feature?

( live demo here: http://coliru.stacked-crooked.com/a/211244ca54c790b8 )

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_2190_886840622.1406301983071
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You can for example catch all exceptions with catch(...) and rethrow
<br>them in a templated function so I think there is no need for a language
<br>feature.
<br></blockquote><div><br>I can implement sizeof...(Ts) entirely using constexpr function templates, does that mean it shouldn't be a language feature? <br><br>( live demo here: http://coliru.stacked-crooked.com/a/211244ca54c790b8 ) <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_2190_886840622.1406301983071--

.

That's a rather different thing. Each catch block generically needs its own body. If the bodies are the same, that indicates you should actually be catching std::exception, dynamic_casting to determine compatibility, and perhaps rethrowing.

Any case where a single catch block is supposed to inspect either of two classes with no common base, you simply need to add that common base.


On 2014-07-25, at 11:26 PM, lorgonjortle@gmail.com wrote:

> I can implement sizeof...(Ts) entirely using constexpr function templates, does that mean it shouldn't be a language feature?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_859_1736520186.1406302602783
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Friday, July 25, 2014 11:32:15 PM UTC+8, David Krauss wrote:
>
> That=E2=80=99s a rather different thing. Each catch block generically nee=
ds its=20
> own body. If the bodies are the same, that indicates you should actually =
be=20
> catching std::exception, dynamic_casting to determine compatibility, and=
=20
> perhaps rethrowing.=20
>
>
It is entirely possible that all of the types listed in the param pack of=
=20
exceptions to catch do not inherit from std::exception, but, perhaps some=
=20
other exception base class for that source base. Perhaps there is no base=
=20
class at all.

Yes, the body of the catch block would need to be generic for each type,=20
but, as with any generic API within the generic paradigm, that doesn't mean=
=20
they should share a common base; they share a common public interface.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_859_1736520186.1406302602783
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Friday, July 25, 2014 11:32:15 PM UTC+8, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">That=E2=80=99s a rath=
er different thing. Each catch block generically needs its own body. If the=
 bodies are the same, that indicates you should actually be catching std::e=
xception, dynamic_casting to determine compatibility, and perhaps rethrowin=
g.
<br>
<br></blockquote><div><br>It is entirely possible that all of the types lis=
ted in the param pack of exceptions to catch do not inherit from std::excep=
tion, but, perhaps some other exception base class for that source base. Pe=
rhaps there is no base class at all.<br><br>Yes, the body of the catch bloc=
k would need to be generic for each type, but, as with any generic API with=
in the generic paradigm, that doesn't mean they should share a common base;=
 they share a common public interface. <br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_859_1736520186.1406302602783--

.

On 2014-07-25, at 11:36 PM, Jeaye Wilkerson <contact@jeaye.com> wrote:

> Yes, the body of the catch block would need to be generic for each type, =
but, as with any generic API within the generic paradigm, that doesn't mean=
 they should share a common base; they share a common public interface.=20

That's just a bad design. The language shouldn't support it. Just because i=
t's possible doesn't mean it's OK.

The exception mechanism is already based on dynamic typing. The environment=
 basically has a super-dynamic_cast which it tries on every potential catch=
 handler. Throwing a non-polymorphic class only sanitizes it by wrapping it=
 in something the dynamic type inspection code will understand. In all case=
s, you're better off adding the polymorphism yourself.

By the way, I also happen to be writing an exception-examining unit test fr=
amework right now.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 25 July 2014 18:44, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-07-25, at 11:36 PM, Jeaye Wilkerson <contact@jeaye.com> wrote:
>
>> Yes, the body of the catch block would need to be generic for each type, but, as with any generic API within the generic paradigm, that doesn't mean they should share a common base; they share a common public interface.
>
> That's just a bad design. The language shouldn't support it. Just because it's possible doesn't mean it's OK.

What's bad design? A library providing multiple exception types that
do not form a hierarchy?
I disagree. There's nothing bad about it. Now, whether we need to
provide a way to generate
the code to catch all those different exception types and run the same
code on all of them is
a different matter.

Work-arounds certainly seem to incur unfortunate costs - using a
variable function template
that re-throws and catches a specific type will lead to one re-throw
per every type in the pack,
as opposed to a single throw that this extension proposal would have.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 25.07.2014 17:26, lorgonjortle@gmail.com wrote:
>
>
>> You can for example catch all exceptions with catch(...) and rethrow
>> them in a templated function so I think there is no need for a language
>> feature.
>>
>
> I can implement sizeof...(Ts) entirely using constexpr function templates,
> does that mean it shouldn't be a language feature?
>
> ( live demo here: http://coliru.stacked-crooked.com/a/211244ca54c790b8 )
>


It would have been nice if you could tell me whether my post helped you.
But nevertheless I think the language has the ability to put almost
everything into a templated function object which works well with
variadic argument packs. Splitting try and catch into different objects
and combine them with function calls is easy. So before making
everything variadic and extend the grammar library solutions can go this
way.
To your example: yes sizeof... can be implemented as a library function
but the committee had the wisdom to place this basic facility in the
standard. I think a fast implementation is essential to meta programming
and the compiler knows the size.

Jan Herrmann

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Friday 25 July 2014 05:58:31 jeaye wrote:
> Unfortunately, the implementation of this is not possible in C++11 or
> C++1y, since param pack expansion in a catch is impossible

You can do that with recursively calling a function that catches the first
exception in a list.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1613_1930694879.1406306249356
Content-Type: text/plain; charset=UTF-8



> It would have been nice if you could tell me whether my post helped you.
>

Sorry! Your snippet did help illustrate, though I had already considered
library-based approach to this. (and found it lacking enough to propose an
alternative here)

Thanks, David; you make a good point about the usefulness of polymorphism
with regard to exceptions. It's a shame though: I agree with Ville that
rethrowing for each type in the pack is not the solution we should strive
for. Any other suggestions that perhaps meet midway between mine and Jan's?

By the way, I also happen to be writing an exception-examining unit test
> framework right now.
>

Small world!

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1613_1930694879.1406306249356
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It would =
have been nice if you could tell me whether my post helped you.=20
<br></blockquote><div><br>Sorry! Your snippet did help illustrate, though I=
 had already considered library-based approach to this. (and found it lacki=
ng enough to propose an alternative here)<br><br>Thanks, David; you make a =
good point about the usefulness of polymorphism with regard to exceptions. =
It's a shame though: I agree with Ville that rethrowing for each type in th=
e pack is not the solution we should strive for. Any other suggestions that=
 perhaps meet midway between mine and Jan's?<br><br><blockquote style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;" class=3D"gmail_quote">By the way, I also happen to be writing =
an exception-examining unit test framework right now.
<br></blockquote><div><br>Small world! <br></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1613_1930694879.1406306249356--

.

On 25.07.2014 18:04, Ville Voutilainen wrote:
> On 25 July 2014 18:44, David Krauss <potswa@gmail.com> wrote:
>>
>> On 2014-07-25, at 11:36 PM, Jeaye Wilkerson <contact@jeaye.com> wrote:
>>
>>> Yes, the body of the catch block would need to be generic for each type, but, as with any generic API within the generic paradigm, that doesn't mean they should share a common base; they share a common public interface.
>>
>> That's just a bad design. The language shouldn't support it. Just because it's possible doesn't mean it's OK.
>
> What's bad design? A library providing multiple exception types that
> do not form a hierarchy?
> I disagree. There's nothing bad about it. Now, whether we need to
> provide a way to generate
> the code to catch all those different exception types and run the same
> code on all of them is
> a different matter.
>
> Work-arounds certainly seem to incur unfortunate costs - using a
> variable function template
> that re-throws and catches a specific type will lead to one re-throw
> per every type in the pack,
> as opposed to a single throw that this extension proposal would have.
>

The first version has another background (it can be used more
dynamically). I have a second version which needs some polishing but
should show my ideas (
http://coliru.stacked-crooked.com/a/0420ce9ae0180306 ):
#include <iostream>
#include <stdexcept>
#include <typeinfo>


template<class Fun, class ExceptionHandler, class ... Exceptions>
struct excpected_exception;

template<class Fun, class ExceptionHandler, class Ex1, class ... Exceptions>
struct excpected_exception<Fun, ExceptionHandler, Ex1, Exceptions...>
{
     void operator()(Fun f, ExceptionHandler eh) {
         try {
             excpected_exception<Fun, ExceptionHandler,
Exceptions...>{}(f, eh);
         } catch (Ex1 const& ex) {
             eh(ex);
         }
     }
};

template<class Fun, class ExceptionHandler>
struct excpected_exception<Fun, ExceptionHandler>
{
     void operator()(Fun f, ExceptionHandler) {
         f();
     }
};

template<class... Ex, class F, class Eh>
void expect_exception(F f, Eh eh) {
     excpected_exception<F, Eh, Ex...>{}(f, eh);
}

struct MyEh {
     template<class Ex>
     void operator()(Ex&& ex) const {
         std::cerr << ex.what() << "(" << typeid(ex).name() << ")" <<
std::endl;
     }
};


int main() {

     expect_exception<std::runtime_error, std::logic_error>([&]{throw
std::runtime_error("Hello");}, MyEh{});
     expect_exception<std::runtime_error, std::logic_error>([&]{throw
std::logic_error("World");;}, MyEh{});

     return 0;
}

The main problem with this version is that exceptions have to be sorted
to bring derived exceptions to front and eventually to bring often
catched exceptions to front. This has to be standardized as well.

Jan Herrmann

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 7/25/2014 7:58 AM, jeaye wrote:
> While implementing a unit test framework in modern C++, I found that I
> wanted an interface for expecting exceptions like:
>
> |
> expect_exception<std::runtime_error>([&]{do_work();});
> |
>
> This lead me to wonder, "what if it were variadic?"
>
> |
> expect_exception<std::runtime_error,std::out_of_range>([&]{do_other_work();});
> |

To be honest, I'm not sure I see the use in this, at least not for your
particular scenario. Like you, I've also been writing a unit test
framework in modern C++[1], but I never found a need for variadic
exception catching; if I expect an exception to be thrown, I want to
test that the *correct* one is thrown, not just that it's one of several
possibilities. While I suppose I can imagine a case where multiple
different types of exceptions could be thrown, I think it'd be rare
enough that I wouldn't worry about trying to handle it generically.

- Jim

[1] http://jimporter.github.io/mettle/


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Friday 25 July 2014 12:29:29 Jim Porter wrote:
> To be honest, I'm not sure I see the use in this, at least not for your
> particular scenario. Like you, I've also been writing a unit test
> framework in modern C++[1], but I never found a need for variadic
> exception catching; if I expect an exception to be thrown, I want to
> test that the *correct* one is thrown, not just that it's one of several
> possibilities. While I suppose I can imagine a case where multiple
> different types of exceptions could be thrown, I think it'd be rare
> enough that I wouldn't worry about trying to handle it generically.

Sometimes, the API being tested may not be able to distinguish an error from
another. You know a certain operation will cause a failure, but you're not
sure which one will be detected. This may be even related to how the OS
reports the issues.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-07-26, at 12:04 AM, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:

> On 25 July 2014 18:44, David Krauss <potswa@gmail.com> wrote:
>>=20
>> On 2014-07-25, at 11:36 PM, Jeaye Wilkerson <contact@jeaye.com> wrote:
>>=20
>>> Yes, the body of the catch block would need to be generic for each type=
, but, as with any generic API within the generic paradigm, that doesn't me=
an they should share a common base; they share a common public interface.
>>=20
>> That's just a bad design. The language shouldn't support it. Just becaus=
e it's possible doesn't mean it's OK.
>=20
> What's bad design? A library providing multiple exception types that
> do not form a hierarchy?
> I disagree. There's nothing bad about it. Now, whether we need to
> provide a way to generate
> the code to catch all those different exception types and run the same
> code on all of them is
> a different matter.

Just to be clear, I meant the latter. If they don't form a hierarchy but th=
ey do have a generic common interface, that's the bad design. There's essen=
tially zero cost to adding a base class, perhaps moving the exception data =
into it at throw time. Exceptions must be movable anyway.

> Work-arounds certainly seem to incur unfortunate costs - using a
> variable function template
> that re-throws and catches a specific type will lead to one re-throw
> per every type in the pack,
> as opposed to a single throw that this extension proposal would have.

I think the suggestion calls for only one catch-all and then a single re-th=
row into a context with all the applicable handlers. Another "workaround," =
more closely equivalent to the variadic catch proposal, is to call the thro=
wing code from a wrapper function which provides the applicable handlers. T=
hat does not sacrifice any efficiency, aside essentially making the try blo=
ck a lambda context.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 7/25/2014 2:14 PM, Thiago Macieira wrote:
> Sometimes, the API being tested may not be able to distinguish an error from
> another. You know a certain operation will cause a failure, but you're not
> sure which one will be detected. This may be even related to how the OS
> reports the issues.

That's true, of course, but I'm not sure it would necessitate a language
feature (even a library feature seems a bit much to me); if I ran into
this, I'd probably be happy with a non-generic solution.

- Jim

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.