------=_Part_338_1066060196.1422448333967
Content-Type: multipart/alternative;
 boundary="----=_Part_339_817647251.1422448333967"

------=_Part_339_817647251.1422448333967
Content-Type: text/plain; charset=UTF-8

I hope I am forgiven for referring to .NET, but there you go ...

C# 6 introduces to C# the notion of Exception Filters (see, e.g.
http://stackoverflow.com/questions/27082069/what-benefit-does-the-new-exception-filter-feature-provide)
where any catch clause can examine the exception it wants to handle *prior
to the stack being unwound*. (The CLR had this for a long time, VB.net also
offers it and basically Win32 SEH __try block always work with execption
filters.)

So, not only do catch clauses become simpler, we can write code that
examines an exception *before* the stack is being unwound, and if the
exception shouldn't be handled, search for a matching catch continues
without unwinding the stack on the spot.

With regard to C++, I was wondering:

* Has this ever been proposed in C++?

* Would the C++ Standard allow implementing such a thing? Would it place
any restrictions on existing exception handling implementations?
(__cxa_throw, etc.)

* Do others think this would be useful?

cheers.

( I will note that I think this is orthogonal to the technicalities of
std::uncaught_exceptionS
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf) )

--

---
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_339_817647251.1422448333967
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I hope I am forgiven for referring to .NET, but there you =
go ...<br><br>C# 6 introduces to C# the notion of Exception Filters (see, e=
..g. http://stackoverflow.com/questions/27082069/what-benefit-does-the-new-e=
xception-filter-feature-provide) where any catch clause can examine the exc=
eption it wants to handle *prior to the stack being unwound*. (The CLR had =
this for a long time, VB.net also offers it and basically Win32 SEH __try b=
lock always work with execption filters.)<br><br>So, not only do catch clau=
ses become simpler, we can write code that examines an exception *before* t=
he stack is being unwound, and if the exception shouldn't be handled, searc=
h for a matching catch continues without unwinding the stack on the spot.<b=
r><br>With regard to C++, I was wondering:<br><br>* Has this ever been prop=
osed in C++?<br><br>* Would the C++ Standard allow implementing such a thin=
g? Would it place any restrictions on existing exception handling implement=
ations? (__cxa_throw, etc.)<br><br>* Do others think this would be useful?<=
br><br>cheers.<br><br>( I will note that I think this is orthogonal to the =
technicalities of std::uncaught_exceptionS (http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2014/n4152.pdf) )<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_339_817647251.1422448333967--
------=_Part_338_1066060196.1422448333967--

.

On 28 January 2015 at 14:32, Martin Ba <0xcdcdcdcd@gmx.at> wrote:
> With regard to C++, I was wondering:
>
> * Has this ever been proposed in C++?

The area has been explored to some extent, see
http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.html

> * Would the C++ Standard allow implementing such a thing? Would it place any
> restrictions on existing exception handling implementations? (__cxa_throw,
> etc.)

I'm not sure. I would recommend looking at the current support
libraries like libsupc++,
they might allow such things already to some extent.

> * Do others think this would be useful?

Certainly.

--

---
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_5544_169913863.1422453367234
Content-Type: multipart/alternative;
 boundary="----=_Part_5545_1736528578.1422453367235"

------=_Part_5545_1736528578.1422453367235
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 28, 2015 at 2:04:37 PM UTC+1, Ville Voutilainen wrote:
>
> On 28 January 2015 at 14:32, Martin Ba <0xcdc...@gmx.at <javascript:>>
> wrote:
> > With regard to C++, I was wondering:
> >
> > * Has this ever been proposed in C++?
>
> The area has been explored to some extent, see
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.html
>
>
>
I will note that N2952 proposes to be able to access the current exception
from within a destructor, that is *during* unwind, while Exception Filters
would run *before* unwind, i.e. before any destructors would run, during
the search phase for any matching handler.

So I think the technical implications for N2952 (and N4152 (N3614)) would
be quite different(?)

cheers.

--

---
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_5545_1736528578.1422453367235
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 28, 2015 at 2:04:37 PM UTC+1, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 Januar=
y 2015 at 14:32, Martin Ba &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"hU_t4nvv464J" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">0xcdc...@gmx.at</a>&gt; wrote:
<br>&gt; With regard to C++, I was wondering:
<br>&gt;
<br>&gt; * Has this ever been proposed in C++?
<br>
<br>The area has been explored to some extent, see
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.ht=
ml" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs=
%2Fpapers%2F2009%2Fn2952.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHbw58Uv7V7=
WTx9FgcWYkR2STaj8w';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers=
%2F2009%2Fn2952.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHbw58Uv7V7WTx9FgcWY=
kR2STaj8w';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/paper=
s/2009/n2952.<wbr>html</a>
<br>
<br><br></blockquote><div><br>I will note that N2952 proposes to be able to=
 access the current exception from within a destructor, that is *during* un=
wind, while Exception Filters would run *before* unwind, i.e. before any de=
structors would run, during the search phase for any matching handler.<br><=
br>So I think the technical implications for N2952 (and N4152 (N3614)) woul=
d be quite different(?)<br><br>cheers.<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_5545_1736528578.1422453367235--
------=_Part_5544_169913863.1422453367234--

.

On 28 January 2015 at 15:56, Martin Ba <0xcdcdcdcd@gmx.at> wrote:
> On Wednesday, January 28, 2015 at 2:04:37 PM UTC+1, Ville Voutilainen wrote:
>>
>> On 28 January 2015 at 14:32, Martin Ba <0xcdc...@gmx.at> wrote:
>> > With regard to C++, I was wondering:
>> >
>> > * Has this ever been proposed in C++?
>>
>> The area has been explored to some extent, see
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.html
>>
>>
>
> I will note that N2952 proposes to be able to access the current exception
> from within a destructor, that is *during* unwind, while Exception Filters
> would run *before* unwind, i.e. before any destructors would run, during the
> search phase for any matching handler.
>
> So I think the technical implications for N2952 (and N4152 (N3614)) would be
> quite different(?)


Perhaps. N2952 as such doesn't explore the idea very far, and the later papers
provide just the count. Running such filters before unwinding seems
tricky to me,
and I don't immediately see why the filters should run before unwinding - unless
the idea is to allow swallowing exceptions before they enter a catch block. Even
in such cases, it seems to matter less whether unwinding is done before or
after the filtering. What N2952 is lightly suggesting is that after
gaining a capability
for inspecting in-flight exceptions, the next potential step would be being
able to transform them - but I don't think I'd envision going as far
as being able to
cancel them.

--

---
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_681_1561036757.1422471183811
Content-Type: multipart/alternative;
 boundary="----=_Part_682_537059500.1422471183811"

------=_Part_682_537059500.1422471183811
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 28, 2015 at 3:10:37 PM UTC+1, Ville Voutilainen wrote:
>
> On 28 January 2015 at 15:56, Martin Ba <0xcdc...@gmx.at <javascript:>>
> wrote:
> > On Wednesday, January 28, 2015 at 2:04:37 PM UTC+1, Ville Voutilainen
> wrote:
> >>
> >> On 28 January 2015 at 14:32, Martin Ba <0xcdc...@gmx.at> wrote:
> >> > With regard to C++, I was wondering:
> >> >
> >> > * Has this ever been proposed in C++?
> >>
> >> The area has been explored to some extent, see
> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.html
> >>
> >>
> >
> > I will note that N2952 proposes to be able to access the current
> exception
> > from within a destructor, that is *during* unwind, while Exception
> Filters
> > would run *before* unwind, i.e. before any destructors would run, during
> the
> > search phase for any matching handler.
> >
> > So I think the technical implications for N2952 (and N4152 (N3614))
> would be
> > quite different(?)
>
>
> Perhaps. N2952 as such doesn't explore the idea very far, and the later
> papers
> provide just the count. Running such filters before unwinding seems
> tricky to me,
> and I don't immediately see why the filters should run before unwinding -
> unless
> the idea is to allow swallowing exceptions before they enter a catch
> block. Even
> in such cases, it seems to matter less whether unwinding is done before or
> after the filtering. What N2952 is lightly suggesting is that after
> gaining a capability
> for inspecting in-flight exceptions, the next potential step would be
> being
> able to transform them - but I don't think I'd envision going as far
> as being able to
> cancel them.
>

It is neither about transforming them, nor about cancelling them - but it
*is* crucial that a filter runs before unwinding starts.

As far as I know unwinding of the stack only starts *once* a matching
handler is found. If no matching handler is found, so a filter should be
able to postpone stack unwinding to a higher level.

This is essential if, eventually, *no* matching handler is found, because
in that case, typical(?) implementations will "dump core" / allow to write
a crash dump prior to the application being terminated.
The crash dump is more useful if no stack unwinding took place, and
Exception Filters would allow for inspecting of exceptions (to decide
whether to catch them), without starting an unwind.

Essentially the same reasoning applies as in the linked SO posts:
(http://stackoverflow.com/a/27082164/321013)

cheers.

--

---
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_682_537059500.1422471183811
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 28, 2015 at 3:10:37 PM UTC+1, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 Januar=
y 2015 at 15:56, Martin Ba &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"-y6RXN99P7UJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">0xcdc...@gmx.at</a>&gt; wrote:
<br>&gt; On Wednesday, January 28, 2015 at 2:04:37 PM UTC+1, Ville Voutilai=
nen wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 28 January 2015 at 14:32, Martin Ba &lt;<a>0xcdc...@gmx.at<=
/a>&gt; wrote:
<br>&gt;&gt; &gt; With regard to C++, I was wondering:
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; * Has this ever been proposed in C++?
<br>&gt;&gt;
<br>&gt;&gt; The area has been explored to some extent, see
<br>&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2009=
/n2952.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG=
21%2Fdocs%2Fpapers%2F2009%2Fn2952.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
bw58Uv7V7WTx9FgcWYkR2STaj8w';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs=
%2Fpapers%2F2009%2Fn2952.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHbw58Uv7V7=
WTx9FgcWYkR2STaj8w';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/d=
ocs/papers/2009/n2952.<wbr>html</a>
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;
<br>&gt; I will note that N2952 proposes to be able to access the current e=
xception
<br>&gt; from within a destructor, that is *during* unwind, while Exception=
 Filters
<br>&gt; would run *before* unwind, i.e. before any destructors would run, =
during the
<br>&gt; search phase for any matching handler.
<br>&gt;
<br>&gt; So I think the technical implications for N2952 (and N4152 (N3614)=
) would be
<br>&gt; quite different(?)
<br>
<br>
<br>Perhaps. N2952 as such doesn't explore the idea very far, and the later=
 papers
<br>provide just the count. Running such filters before unwinding seems
<br>tricky to me,
<br>and I don't immediately see why the filters should run before unwinding=
 - unless
<br>the idea is to allow swallowing exceptions before they enter a catch bl=
ock. Even
<br>in such cases, it seems to matter less whether unwinding is done before=
 or
<br>after the filtering. What N2952 is lightly suggesting is that after
<br>gaining a capability
<br>for inspecting in-flight exceptions, the next potential step would be b=
eing
<br>able to transform them - but I don't think I'd envision going as far
<br>as being able to
<br>cancel them.
<br></blockquote><div><br>It is neither about transforming them, nor about =
cancelling them - but it *is* crucial that a filter runs before unwinding s=
tarts.<br><br>As far as I know unwinding of the stack only starts *once* a =
matching handler is found. If no matching handler is found, so a filter sho=
uld be able to postpone stack unwinding to a higher level.<br><br>This is e=
ssential if, eventually, *no* matching handler is found, because in that ca=
se, typical(?) implementations will "dump core" / allow to write a crash du=
mp prior to the application being terminated.<br>The crash dump is more use=
ful if no stack unwinding took place, and Exception Filters would allow for=
 inspecting of exceptions (to decide whether to catch them), without starti=
ng an unwind.<br><br>Essentially the same reasoning applies as in the linke=
d SO posts: (http://stackoverflow.com/a/27082164/321013)<br><br>cheers.<br>=
<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_682_537059500.1422471183811--
------=_Part_681_1561036757.1422471183811--

.

------=_Part_803_442428329.1422475117100
Content-Type: multipart/alternative;
 boundary="----=_Part_804_1304539589.1422475117100"

------=_Part_804_1304539589.1422475117100
Content-Type: text/plain; charset=UTF-8

To me it seems that the main benefit of an exception filtering mechanism is
that you can conditionally catch an exception based not only on its type
but on its contents,
just as shown in the C# examples. Today the only way of doing this is
catching the exception, then if it doesn't match your criterion do a
rethrow of it, which, in C++ as in C# will
not check succeding catch() clauses in the same try statement.

As we still deal with legacy interfaces with integer error codes quite a
lot I see some benefit to this approach as it is easier to just throw an
exception with the non-ok error code as a member than implementing
a switch to throw different exception classes for each low level error
code. Not many do that, in my experience, and in addition creating all of
these individual exception classes is a hazzle.

I like this idea more as I think of it more: It seems that the concept of
having to decide which catch clause to enter based only on the exception's
type only is rather weak.


Den onsdag 28 januari 2015 kl. 19:53:03 UTC+1 skrev Martin Ba:
>
> On Wednesday, January 28, 2015 at 3:10:37 PM UTC+1, Ville Voutilainen
> wrote:
>>
>> On 28 January 2015 at 15:56, Martin Ba <0xcdc...@gmx.at> wrote:
>> > On Wednesday, January 28, 2015 at 2:04:37 PM UTC+1, Ville Voutilainen
>> wrote:
>> >>
>> >> On 28 January 2015 at 14:32, Martin Ba <0xcdc...@gmx.at> wrote:
>> >> > With regard to C++, I was wondering:
>> >> >
>> >> > * Has this ever been proposed in C++?
>> >>
>> >> The area has been explored to some extent, see
>> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2952.html
>> >>
>> >>
>> >
>> > I will note that N2952 proposes to be able to access the current
>> exception
>> > from within a destructor, that is *during* unwind, while Exception
>> Filters
>> > would run *before* unwind, i.e. before any destructors would run,
>> during the
>> > search phase for any matching handler.
>> >
>> > So I think the technical implications for N2952 (and N4152 (N3614))
>> would be
>> > quite different(?)
>>
>>
>> Perhaps. N2952 as such doesn't explore the idea very far, and the later
>> papers
>> provide just the count. Running such filters before unwinding seems
>> tricky to me,
>> and I don't immediately see why the filters should run before unwinding -
>> unless
>> the idea is to allow swallowing exceptions before they enter a catch
>> block. Even
>> in such cases, it seems to matter less whether unwinding is done before
>> or
>> after the filtering. What N2952 is lightly suggesting is that after
>> gaining a capability
>> for inspecting in-flight exceptions, the next potential step would be
>> being
>> able to transform them - but I don't think I'd envision going as far
>> as being able to
>> cancel them.
>>
>
> It is neither about transforming them, nor about cancelling them - but it
> *is* crucial that a filter runs before unwinding starts.
>
> As far as I know unwinding of the stack only starts *once* a matching
> handler is found. If no matching handler is found, so a filter should be
> able to postpone stack unwinding to a higher level.
>
> This is essential if, eventually, *no* matching handler is found, because
> in that case, typical(?) implementations will "dump core" / allow to write
> a crash dump prior to the application being terminated.
> The crash dump is more useful if no stack unwinding took place, and
> Exception Filters would allow for inspecting of exceptions (to decide
> whether to catch them), without starting an unwind.
>
> Essentially the same reasoning applies as in the linked SO posts: (
> http://stackoverflow.com/a/27082164/321013)
>
> cheers.
>
>

--

---
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_804_1304539589.1422475117100
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">To me it seems that the main benefit of an exception filte=
ring mechanism is that you can conditionally catch an exception based not o=
nly on its type but on its contents,<div>just as shown in the C# examples. =
Today the only way of doing this is catching the exception, then if it does=
n't match your criterion do a rethrow of it, which, in C++ as in C# will</d=
iv><div>not check succeding catch() clauses in the same try statement.</div=
><div><br></div><div>As we still deal with legacy interfaces with integer e=
rror codes quite a lot I see some benefit to this approach as it is easier =
to just throw an exception with the non-ok error code as a member than impl=
ementing</div><div>a switch to throw different exception classes for each l=
ow level error code. Not many do that, in my experience, and in addition cr=
eating all of these individual exception classes is a hazzle.</div><div><br=
></div><div>I like this idea more as I think of it more: It seems that the =
concept of having to decide which catch clause to enter based only on the e=
xception's type only is rather weak.</div><div><div><br><br>Den onsdag 28 j=
anuari 2015 kl. 19:53:03 UTC+1 skrev Martin Ba:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">On Wednesday, January 28, 2015 at 3:10:37=
 PM UTC+1, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On 28 January 2015 at 15:56, Martin Ba &lt;<a rel=3D"nofollow">0xcdc...@gm=
x.at</a>&gt; wrote:
<br>&gt; On Wednesday, January 28, 2015 at 2:04:37 PM UTC+1, Ville Voutilai=
nen wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 28 January 2015 at 14:32, Martin Ba &lt;<a>0xcdc...@gmx.at<=
/a>&gt; wrote:
<br>&gt;&gt; &gt; With regard to C++, I was wondering:
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; * Has this ever been proposed in C++?
<br>&gt;&gt;
<br>&gt;&gt; The area has been explored to some extent, see
<br>&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2009=
/n2952.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG=
21%2Fdocs%2Fpapers%2F2009%2Fn2952.html\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
bw58Uv7V7WTx9FgcWYkR2STaj8w';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs=
%2Fpapers%2F2009%2Fn2952.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHbw58Uv7V7=
WTx9FgcWYkR2STaj8w';return true;">http://open-std.org/JTC1/SC22/<wbr>WG21/d=
ocs/papers/2009/n2952.<wbr>html</a>
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;
<br>&gt; I will note that N2952 proposes to be able to access the current e=
xception
<br>&gt; from within a destructor, that is *during* unwind, while Exception=
 Filters
<br>&gt; would run *before* unwind, i.e. before any destructors would run, =
during the
<br>&gt; search phase for any matching handler.
<br>&gt;
<br>&gt; So I think the technical implications for N2952 (and N4152 (N3614)=
) would be
<br>&gt; quite different(?)
<br>
<br>
<br>Perhaps. N2952 as such doesn't explore the idea very far, and the later=
 papers
<br>provide just the count. Running such filters before unwinding seems
<br>tricky to me,
<br>and I don't immediately see why the filters should run before unwinding=
 - unless
<br>the idea is to allow swallowing exceptions before they enter a catch bl=
ock. Even
<br>in such cases, it seems to matter less whether unwinding is done before=
 or
<br>after the filtering. What N2952 is lightly suggesting is that after
<br>gaining a capability
<br>for inspecting in-flight exceptions, the next potential step would be b=
eing
<br>able to transform them - but I don't think I'd envision going as far
<br>as being able to
<br>cancel them.
<br></blockquote><div><br>It is neither about transforming them, nor about =
cancelling them - but it *is* crucial that a filter runs before unwinding s=
tarts.<br><br>As far as I know unwinding of the stack only starts *once* a =
matching handler is found. If no matching handler is found, so a filter sho=
uld be able to postpone stack unwinding to a higher level.<br><br>This is e=
ssential if, eventually, *no* matching handler is found, because in that ca=
se, typical(?) implementations will "dump core" / allow to write a crash du=
mp prior to the application being terminated.<br>The crash dump is more use=
ful if no stack unwinding took place, and Exception Filters would allow for=
 inspecting of exceptions (to decide whether to catch them), without starti=
ng an unwind.<br><br>Essentially the same reasoning applies as in the linke=
d SO posts: (<a href=3D"http://stackoverflow.com/a/27082164/321013" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fa%2F27082164%2F321013\46sa\75D=
\46sntz\0751\46usg\75AFQjCNH6idcxRiiDsiwyYIXP49SP_acTgw';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflo=
w.com%2Fa%2F27082164%2F321013\46sa\75D\46sntz\0751\46usg\75AFQjCNH6idcxRiiD=
siwyYIXP49SP_acTgw';return true;">http://stackoverflow.com/a/<wbr>27082164/=
321013</a>)<br><br>cheers.<br><br></div></div></blockquote></div></div></di=
v>

<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_804_1304539589.1422475117100--
------=_Part_803_442428329.1422475117100--

.

------=_Part_6156_2096295912.1422521638283
Content-Type: multipart/alternative;
 boundary="----=_Part_6157_828680302.1422521638283"

------=_Part_6157_828680302.1422521638283
Content-Type: text/plain; charset=UTF-8

On Wednesday, January 28, 2015 at 8:58:37 PM UTC+1, Bengt Gustafsson wrote:
>
> To me it seems that the main benefit of an exception filtering mechanism
> is that you can conditionally catch an exception based not only on its type
> but on its contents,
> just as shown in the C# examples. Today the only way of doing this is
> catching the exception, then if it doesn't match your criterion do a
> rethrow of it, which, in C++ as in C# will
> not check succeding catch() clauses in the same try statement.
>
> As we still deal with legacy interfaces with integer error codes quite a
> lot I see some benefit to this approach as it is easier to just throw an
> exception with the non-ok error code as a member than implementing
> a switch to throw different exception classes for each low level error
> code. Not many do that, in my experience, and in addition creating all of
> these individual exception classes is a hazzle.
>
> I like this idea more as I think of it more: It seems that the concept of
> having to decide which catch clause to enter based only on the exception's
> type only is rather weak.
>
>
I fully agree, that is why I asked whether anyone has ever looked into this
for C++. :-)

--

---
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_6157_828680302.1422521638283
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, January 28, 2015 at 8:58:37 PM UTC+1, Bengt =
Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">To me it seems that the main benefit of an exception filtering mechanis=
m is that you can conditionally catch an exception based not only on its ty=
pe but on its contents,<div>just as shown in the C# examples. Today the onl=
y way of doing this is catching the exception, then if it doesn't match you=
r criterion do a rethrow of it, which, in C++ as in C# will</div><div>not c=
heck succeding catch() clauses in the same try statement.</div><div><br></d=
iv><div>As we still deal with legacy interfaces with integer error codes qu=
ite a lot I see some benefit to this approach as it is easier to just throw=
 an exception with the non-ok error code as a member than implementing</div=
><div>a switch to throw different exception classes for each low level erro=
r code. Not many do that, in my experience, and in addition creating all of=
 these individual exception classes is a hazzle.</div><div><br></div><div>I=
 like this idea more as I think of it more: It seems that the concept of ha=
ving to decide which catch clause to enter based only on the exception's ty=
pe only is rather weak.</div><div><div><div dir=3D"ltr"><div><br></div></di=
v></div></div></div></blockquote><div><br>I fully agree, that is why I aske=
d whether anyone has ever looked into this for C++. :-)<br><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_6157_828680302.1422521638283--
------=_Part_6156_2096295912.1422521638283--

.