Topic: Nested exceptions
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Mon, 20 Apr 2015 06:20:22 +0300
Raw View
This is a multi-part message in MIME format.
--------------080007040900040907090103
Content-Type: text/plain; charset=UTF-8
Hi all,
This, I think, is the most sore point in C++ today. Exception nesting.
Current standard mandates that an exception thrown during stack unwind
for another exception causes immediate program termination. This has led
to many suggestions that destructors never throw. I find that suggestion
both problematic and too onerous.
It is problematic because in 99% of the cases, it is quite alright for
destructors to throw. In other words, there are two types of C++
programmers. Those who never heard of the problem, those who think it is
illegal for a destructor to throw, and those... three types of C++
programmers.
This restriction is also too onerous. If an operation that needs to be
done during destruction fails, the programmer is left with zero options
as to what to do about it. There is, in fact, no way for the programmer
to report this failure, or to act about it. The only advice I offer
people (and follow it myself) is: disregard the threat, throw from the
destructor. This effectively places me in the same group as the most
ignorant of the two three.
In fact, this restriction is so onerous, that I have seen code where the
destructor is declared as "nothrow", but also throws. This is obvious
mistake was done by someone aware of the problem, and yet, when push
comes to shove, he needed to report the error somehow.
What I suggest:
The simplest solution to this problem is to simply ignore the new
exception. There are zero cases where the programmer is worse off than
she is today. In all likelihood, the second exception is a byproduct of
the first one anyways.
An alternative solution, but a more complicated one, is to employ
excption chaining, such as the one used by D. This has several
challenges to implement. For one thing, the exception needs to be
chained to something. As long as C++ allows throwing just any ol' thing,
that simply cannot be done. I think a reasonable compromise on that
front is to add a chain pointer to std::exception, and chain the new
exception only if the types line up (i.e. - if both end of chain object
and newly thrown object derive from std::exception).
An even more generic solution (not sure that's a good thing, mind you)
is to define some interface, and allow chaining if the static types line
up. I.e. - if the existing end of chain object has a function called
"chain_exception" that is capable of accepting a pointer to the object
currently being thrown. I'm not confident I understand the exception
mechanism well enough, but I suspect this would incur a run time cost
that is, probably, not worth the trouble.
Personally, I'm perfectly happy with option 1: discard the new
exception. It is simple, easy to implement, covers most of the cases and
has zero down sides compared to the situation as it is today.
All of the above does not refer to errors thrown during construction and
destruction of the exception object itself. Personally, I'm perfectly
fine with leaving the situation there as it is today. It is perfectly
valid, in my eyes, to require greater care from programmers designing
exception objects than from programmers merely using them.
Shachar
--
---
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/.
--------------080007040900040907090103
Content-Type: text/html; charset=UTF-8
<html style="direction: ltr;">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;" bidimailui-charset-is-forced="true"
bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
This, I think, is the most sore point in C++ today. Exception
nesting.<br>
<br>
Current standard mandates that an exception thrown during stack
unwind for another exception causes immediate program termination.
This has led to many suggestions that destructors never throw. I
find that suggestion both problematic and too onerous.<br>
<br>
It is problematic because in 99% of the cases, it is quite alright
for destructors to throw. In other words, there are two types of C++
programmers. Those who never heard of the problem, those who think
it is illegal for a destructor to throw, and those... three types of
C++ programmers.<br>
<br>
This restriction is also too onerous. If an operation that needs to
be done during destruction fails, the programmer is left with zero
options as to what to do about it. There is, in fact, no way for the
programmer to report this failure, or to act about it. The only
advice I offer people (and follow it myself) is: disregard the
threat, throw from the destructor. This effectively places me in the
same group as the most ignorant of the <strike>two</strike> three.<br>
<br>
In fact, this restriction is so onerous, that I have seen code where
the destructor is declared as "nothrow", but also throws. This is
obvious mistake was done by someone aware of the problem, and yet,
when push comes to shove, he needed to report the error somehow.<br>
<br>
What I suggest:<br>
The simplest solution to this problem is to simply ignore the new
exception. There are zero cases where the programmer is worse off
than she is today. In all likelihood, the second exception is a
byproduct of the first one anyways.<br>
<br>
An alternative solution, but a more complicated one, is to employ
excption chaining, such as the one used by D. This has several
challenges to implement. For one thing, the exception needs to be
chained to something. As long as C++ allows throwing just any ol'
thing, that simply cannot be done. I think a reasonable compromise
on that front is to add a chain pointer to std::exception, and chain
the new exception only if the types line up (i.e. - if both end of
chain object and newly thrown object derive from std::exception).<br>
<br>
An even more generic solution (not sure that's a good thing, mind
you) is to define some interface, and allow chaining if the static
types line up. I.e. - if the existing end of chain object has a
function called "chain_exception" that is capable of accepting a
pointer to the object currently being thrown. I'm not confident I
understand the exception mechanism well enough, but I suspect this
would incur a run time cost that is, probably, not worth the
trouble.<br>
<br>
Personally, I'm perfectly happy with option 1: discard the new
exception. It is simple, easy to implement, covers most of the cases
and has zero down sides compared to the situation as it is today.<br>
<br>
All of the above does not refer to errors thrown during construction
and destruction of the exception object itself. Personally, I'm
perfectly fine with leaving the situation there as it is today. It
is perfectly valid, in my eyes, to require greater care from
programmers designing exception objects than from programmers merely
using them.<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
--------------080007040900040907090103--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 22 Apr 2015 11:23:24 -0700
Raw View
On Monday 20 April 2015 06:20:22 Shachar Shemesh wrote:
> What I suggest:
> The simplest solution to this problem is to simply ignore the new
> exception. There are zero cases where the programmer is worse off than
> she is today. In all likelihood, the second exception is a byproduct of
> the first one anyways.
That's probably a much worse scenario.
Imagine the following code:
try {
someCode();
someCode2();
} catch (...) {
...
}
someOtherCode();
if someCode() throws, where would you expect execution to continue?
--
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/.
.
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Wed, 22 Apr 2015 20:31:20 +0200
Raw View
2015-04-20 5:20 GMT+02:00 Shachar Shemesh <shachar@lingnu.com>:
> Hi all,
>
> This, I think, is the most sore point in C++ today. Exception nesting.
>
> Current standard mandates that an exception thrown during stack unwind for
> another exception causes immediate program termination. This has led to many
> suggestions that destructors never throw. I find that suggestion both
> problematic and too onerous.
>
> It is problematic because in 99% of the cases, it is quite alright for
> destructors to throw. In other words, there are two types of C++
> programmers. Those who never heard of the problem, those who think it is
> illegal for a destructor to throw, and those... three types of C++
> programmers.
>
> This restriction is also too onerous. If an operation that needs to be done
> during destruction fails, the programmer is left with zero options as to
> what to do about it. There is, in fact, no way for the programmer to report
> this failure, or to act about it. The only advice I offer people (and follow
> it myself) is: disregard the threat, throw from the destructor. This
> effectively places me in the same group as the most ignorant of the two
> three.
>
> In fact, this restriction is so onerous, that I have seen code where the
> destructor is declared as "nothrow", but also throws. This is obvious
> mistake was done by someone aware of the problem, and yet, when push comes
> to shove, he needed to report the error somehow.
>
> What I suggest:
> The simplest solution to this problem is to simply ignore the new exception.
> There are zero cases where the programmer is worse off than she is today. In
> all likelihood, the second exception is a byproduct of the first one
> anyways.
>
> An alternative solution, but a more complicated one, is to employ excption
> chaining, such as the one used by D. This has several challenges to
> implement. For one thing, the exception needs to be chained to something. As
> long as C++ allows throwing just any ol' thing, that simply cannot be done.
> I think a reasonable compromise on that front is to add a chain pointer to
> std::exception, and chain the new exception only if the types line up (i.e.
> - if both end of chain object and newly thrown object derive from
> std::exception).
>
> An even more generic solution (not sure that's a good thing, mind you) is to
> define some interface, and allow chaining if the static types line up. I.e.
> - if the existing end of chain object has a function called
> "chain_exception" that is capable of accepting a pointer to the object
> currently being thrown. I'm not confident I understand the exception
> mechanism well enough, but I suspect this would incur a run time cost that
> is, probably, not worth the trouble.
>
> Personally, I'm perfectly happy with option 1: discard the new exception. It
> is simple, easy to implement, covers most of the cases and has zero down
> sides compared to the situation as it is today.
>
> All of the above does not refer to errors thrown during construction and
> destruction of the exception object itself. Personally, I'm perfectly fine
> with leaving the situation there as it is today. It is perfectly valid, in
> my eyes, to require greater care from programmers designing exception
> objects than from programmers merely using them.
>
A question: Have you considered that this also changes the meaning of
programs that don't terminate at all?
#include <iostream>
struct Hello {
~Hello() {
try {
throw "Hello";
}
catch(const char *x) { std::cout << x; }
}
};
int main() {
try {
Hello hello;
throw "World";
}
catch(const char *y) { std::cout << y; }
}
This program prints HelloWorld, and you are going to make this print
Hello, if I understand you correctly.
--
---
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/.
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Wed, 22 Apr 2015 11:33:58 -0700
Raw View
--001a11c367ec0022e6051454682d
Content-Type: text/plain; charset=UTF-8
Can't you implement option 1 yourself? If you really think it is sensible
to have the second exception ignored if it occurs during stack unwinding,
then something like this (there are probably edge cases I am missing...)
should work:
Foo::~Foo() try {
// body of destructor
} catch (...) {
if (std::uncaught_exceptions() > 0) {
// log the exception maybe
return; // swallow the exception
} else {
throw; // actually, this can be omitted; the exception will be
automatically rethrown
}
}
On Sun, Apr 19, 2015 at 8:20 PM, Shachar Shemesh <shachar@lingnu.com> wrote:
> Hi all,
>
> This, I think, is the most sore point in C++ today. Exception nesting.
>
> Current standard mandates that an exception thrown during stack unwind for
> another exception causes immediate program termination. This has led to
> many suggestions that destructors never throw. I find that suggestion both
> problematic and too onerous.
>
> It is problematic because in 99% of the cases, it is quite alright for
> destructors to throw. In other words, there are two types of C++
> programmers. Those who never heard of the problem, those who think it is
> illegal for a destructor to throw, and those... three types of C++
> programmers.
>
> This restriction is also too onerous. If an operation that needs to be
> done during destruction fails, the programmer is left with zero options as
> to what to do about it. There is, in fact, no way for the programmer to
> report this failure, or to act about it. The only advice I offer people
> (and follow it myself) is: disregard the threat, throw from the destructor.
> This effectively places me in the same group as the most ignorant of the
> two three.
>
> In fact, this restriction is so onerous, that I have seen code where the
> destructor is declared as "nothrow", but also throws. This is obvious
> mistake was done by someone aware of the problem, and yet, when push comes
> to shove, he needed to report the error somehow.
>
> What I suggest:
> The simplest solution to this problem is to simply ignore the new
> exception. There are zero cases where the programmer is worse off than she
> is today. In all likelihood, the second exception is a byproduct of the
> first one anyways.
>
> An alternative solution, but a more complicated one, is to employ excption
> chaining, such as the one used by D. This has several challenges to
> implement. For one thing, the exception needs to be chained to something.
> As long as C++ allows throwing just any ol' thing, that simply cannot be
> done. I think a reasonable compromise on that front is to add a chain
> pointer to std::exception, and chain the new exception only if the types
> line up (i.e. - if both end of chain object and newly thrown object derive
> from std::exception).
>
> An even more generic solution (not sure that's a good thing, mind you) is
> to define some interface, and allow chaining if the static types line up.
> I.e. - if the existing end of chain object has a function called
> "chain_exception" that is capable of accepting a pointer to the object
> currently being thrown. I'm not confident I understand the exception
> mechanism well enough, but I suspect this would incur a run time cost that
> is, probably, not worth the trouble.
>
> Personally, I'm perfectly happy with option 1: discard the new exception.
> It is simple, easy to implement, covers most of the cases and has zero down
> sides compared to the situation as it is today.
>
> All of the above does not refer to errors thrown during construction and
> destruction of the exception object itself. Personally, I'm perfectly fine
> with leaving the situation there as it is today. It is perfectly valid, in
> my eyes, to require greater care from programmers designing exception
> objects than from programmers merely using them.
>
> Shachar
>
> --
>
> ---
> 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/.
>
--
*Brian Bi*
--
---
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/.
--001a11c367ec0022e6051454682d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Can't you implement option 1 yourself? If you really t=
hink it is sensible to have the second exception ignored if it occurs durin=
g stack unwinding, then something like this (there are probably edge cases =
I am missing...) should work:<div><br></div><div>=C2=A0 =C2=A0 Foo::~Foo() =
try {</div><div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 // body of destructor</div=
><div>=C2=A0 =C2=A0=C2=A0} catch (...) {</div><div>=C2=A0 =C2=A0=C2=A0=C2=
=A0 =C2=A0 if (std::uncaught_exceptions() > 0) {</div><div>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // log the exception maybe</div><div>=C2=A0 =
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 return; // swallow the excepti=
on</div><div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 } else {</div><div>=C2=A0 =C2=
=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 throw; // actually, this can be o=
mitted; the exception will be automatically rethrown</div><div>=C2=A0 =C2=
=A0=C2=A0=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0=C2=A0}</div></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Apr 19, 2015 at 8=
:20 PM, Shachar Shemesh <span dir=3D"ltr"><<a href=3D"mailto:shachar@lin=
gnu.com" target=3D"_blank">shachar@lingnu.com</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
=20
=20
=20
=20
<div style=3D"direction:ltr" bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi all,<br>
<br>
This, I think, is the most sore point in C++ today. Exception
nesting.<br>
<br>
Current standard mandates that an exception thrown during stack
unwind for another exception causes immediate program termination.
This has led to many suggestions that destructors never throw. I
find that suggestion both problematic and too onerous.<br>
<br>
It is problematic because in 99% of the cases, it is quite alright
for destructors to throw. In other words, there are two types of C++
programmers. Those who never heard of the problem, those who think
it is illegal for a destructor to throw, and those... three types of
C++ programmers.<br>
<br>
This restriction is also too onerous. If an operation that needs to
be done during destruction fails, the programmer is left with zero
options as to what to do about it. There is, in fact, no way for the
programmer to report this failure, or to act about it. The only
advice I offer people (and follow it myself) is: disregard the
threat, throw from the destructor. This effectively places me in the
same group as the most ignorant of the <strike>two</strike> three.<br>
<br>
In fact, this restriction is so onerous, that I have seen code where
the destructor is declared as "nothrow", but also throws. Thi=
s is
obvious mistake was done by someone aware of the problem, and yet,
when push comes to shove, he needed to report the error somehow.<br>
<br>
What I suggest:<br>
The simplest solution to this problem is to simply ignore the new
exception. There are zero cases where the programmer is worse off
than she is today. In all likelihood, the second exception is a
byproduct of the first one anyways.<br>
<br>
An alternative solution, but a more complicated one, is to employ
excption chaining, such as the one used by D. This has several
challenges to implement. For one thing, the exception needs to be
chained to something. As long as C++ allows throwing just any ol'
thing, that simply cannot be done. I think a reasonable compromise
on that front is to add a chain pointer to std::exception, and chain
the new exception only if the types line up (i.e. - if both end of
chain object and newly thrown object derive from std::exception).<br>
<br>
An even more generic solution (not sure that's a good thing, mind
you) is to define some interface, and allow chaining if the static
types line up. I.e. - if the existing end of chain object has a
function called "chain_exception" that is capable of acceptin=
g a
pointer to the object currently being thrown. I'm not confident I
understand the exception mechanism well enough, but I suspect this
would incur a run time cost that is, probably, not worth the
trouble.<br>
<br>
Personally, I'm perfectly happy with option 1: discard the new
exception. It is simple, easy to implement, covers most of the cases
and has zero down sides compared to the situation as it is today.<br>
<br>
All of the above does not refer to errors thrown during construction
and destruction of the exception object itself. Personally, I'm
perfectly fine with leaving the situation there as it is today. It
is perfectly valid, in my eyes, to require greater care from
programmers designing exception objects than from programmers merely
using them.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Shachar<br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><fo=
nt color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div><=
/div></div></div></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" 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 />
--001a11c367ec0022e6051454682d--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 23 Apr 2015 10:00:28 +0800
Raw View
--Apple-Mail=_63ED2DB0-EA49-4700-BCE7-765F022A081B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9320, at 11:20 AM, Shachar Shemesh <shachar@ling=
nu.com> wrote:
>=20
> What I suggest:
> The simplest solution to this problem is to simply ignore the new excepti=
on. There are zero cases where the programmer is worse off than she is toda=
y.
There are cases where terminating the program is better than continuing it =
with invalid inputs or broken preconditions.
> In all likelihood, the second exception is a byproduct of the first one =
anyways.
Regardless, the program isn=E2=80=99t going to handle both if the first one=
hasn=E2=80=99t been caught when the second is thrown.
> An alternative solution, but a more complicated one, is to employ excptio=
n chaining, such as the one used by D. This has several challenges to imple=
ment. For one thing, the exception needs to be chained to something.
std::throw_with_nested and std::nested_exception (since C++11) do this with=
generic inheritance and polymorphism.
> As long as C++ allows throwing just any ol' thing, that simply cannot be =
done. I think a reasonable compromise on that front is to add a chain point=
er to std::exception, and chain the new exception only if the types line up=
(i.e. - if both end of chain object and newly thrown object derive from st=
d::exception).
The existing solution is even better: No core language or ABI modification,=
and it works with all class types. No need for conformance to a generic in=
terface, either.
> An even more generic solution (not sure that's a good thing, mind you) is=
to define some interface, and allow chaining if the static types line up. =
I.e. - if the existing end of chain object has a function called "chain_exc=
eption" that is capable of accepting a pointer to the object currently bein=
g thrown.
This can be achieved using nested_exception::rethrow_nested with a catch cl=
ause matching the expected static type.
C++ could make nested exception generation the default, but it would tend t=
o hide the nested exceptions. Until the user adds nested_exception handlers=
, it=E2=80=99s no better than ignoring and replacing the first exception wi=
th the second. That path wasn=E2=80=99t taken because it=E2=80=99s unsafe.
Correct code handles all exceptions as soon and unexceptionally as possible=
, and explicitly swallows all exceptions that will be safely ignored.
--=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/.
--Apple-Mail=_63ED2DB0-EA49-4700-BCE7-765F022A081B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9320, at 11:20 AM, Shachar Shemesh <<a href=3D"mailto:shachar@lin=
gnu.com" class=3D"">shachar@lingnu.com</a>> wrote:</div><br class=3D"App=
le-interchange-newline"><div class=3D""><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-=
color: rgb(255, 255, 255); float: none; display: inline !important;" class=
=3D"">What I suggest:</span><br style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255=
, 255, 255);" class=3D""><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255,=
255, 255); float: none; display: inline !important;" class=3D"">The simple=
st solution to this problem is to simply ignore the new exception. There ar=
e zero cases where the programmer is worse off than she is today.</span></d=
iv></blockquote><div><br class=3D""></div><div>There are cases where termin=
ating the program is better than continuing it with invalid inputs or broke=
n preconditions.</div><br class=3D""><blockquote type=3D"cite" class=3D""><=
/blockquote><blockquote type=3D"cite" class=3D""><div class=3D""><span styl=
e=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-vari=
ant: normal; font-weight: normal; letter-spacing: normal; line-height: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px; background-color: rgb(255, 255, 255); float: none; display: i=
nline !important;" class=3D""> In all likelihood, the second exception=
is a byproduct of the first one anyways.</span><br style=3D"font-family: H=
elvetica; font-size: 12px; font-style: normal; font-variant: normal; font-w=
eight: normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: nor=
mal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; backg=
round-color: rgb(255, 255, 255);" class=3D""></div></blockquote><div><br cl=
ass=3D""></div><div>Regardless, the program isn=E2=80=99t going to handle b=
oth if the first one hasn=E2=80=99t been caught when the second is thrown.<=
/div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><s=
pan style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; di=
splay: inline !important;" class=3D"">An alternative solution, but a more c=
omplicated one, is to employ excption chaining, such as the one used by D. =
This has several challenges to implement. For one thing, the exception need=
s to be chained to something.</span></div></blockquote><div><br class=3D"">=
</div><div><font face=3D"Courier" class=3D"">std::throw_with_nested</font> =
and <font face=3D"Courier" class=3D"">std::nested_exception</font> (si=
nce C++11) do this with generic inheritance and polymorphism.</div><br clas=
s=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span style=3D"=
font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px; background-color: rgb(255, 255, 255); float: none; display: inline=
!important;" class=3D"">As long as C++ allows throwing just any ol' thing,=
that simply cannot be done. </span><span style=3D"background-color: r=
gb(255, 255, 255);" class=3D"">I think a reasonable compromise on that fron=
t is to add a chain pointer to std::exception, and chain the new exception =
only if the types line up (i.e. - if both end of chain object and newly thr=
own object derive from std::exception).</span></div></blockquote><div><br c=
lass=3D""></div><div>The existing solution is even better: No core language=
or ABI modification, and it works with all class types. No need for confor=
mance to a generic interface, either.</div><br class=3D""><blockquote type=
=3D"cite" class=3D""></blockquote><blockquote type=3D"cite" class=3D""><div=
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); f=
loat: none; display: inline !important;" class=3D"">An even more generic so=
lution (not sure that's a good thing, mind you) is to define some interface=
, and allow chaining if the static types line up. I.e. - if the existing en=
d of chain object has a function called "chain_exception" that is capable o=
f accepting a pointer to the object currently being thrown.</span></div></b=
lockquote><br class=3D""></div><div>This can be achieved using <font f=
ace=3D"Courier" class=3D"">nested_exception::rethrow_nested</font> wit=
h a <font face=3D"Courier" class=3D"">catch</font> clause matching the expe=
cted static type.</div><br class=3D""><div class=3D"">C++ could m=
ake nested exception generation the default, but it would tend to hide the =
nested exceptions. Until the user adds <font face=3D"Courier" class=3D"">ne=
sted_exception</font> handlers, it=E2=80=99s no better than ignoring and re=
placing the first exception with the second. That path wasn=E2=80=99t taken=
because it=E2=80=99s unsafe.</div><div class=3D""><br class=3D""></div><di=
v class=3D"">Correct code handles all exceptions as soon and unexceptionall=
y as possible, and explicitly swallows all exceptions that will be safely i=
gnored.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_63ED2DB0-EA49-4700-BCE7-765F022A081B--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Thu, 23 Apr 2015 22:09:48 +0300
Raw View
This is a multi-part message in MIME format.
--------------040400050203020307050903
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm sorry if this is a dup. I'm having some mail server problems.
On 23/04/15 05:00, David Krauss wrote:
>
>> On 2015=E2=80=9304=E2=80=9320, at 11:20 AM, Shachar Shemesh <shachar@lin=
gnu.com
>> <mailto:shachar@lingnu.com>> wrote:
>>
>> What I suggest:
>> The simplest solution to this problem is to simply ignore the new
>> exception. There are zero cases where the programmer is worse off
>> than she is today.
>
> There are cases where terminating the program is better than
> continuing it with invalid inputs or broken preconditions.
The question is the opposite, I think. Are there cases where terminating
the program makes little sense? I'd argue that with RAII properly
implemented, that would be the rule, rather than the exception.
>
>> In all likelihood, the second exception is a byproduct of the first
>> one anyways.
>
> Regardless, the program isn=E2=80=99t going to handle both if the first o=
ne
> hasn=E2=80=99t been caught when the second is thrown.
Hasn't been caught *yet*.
>
>> An alternative solution, but a more complicated one, is to employ
>> excption chaining, such as the one used by D. This has several
>> challenges to implement. For one thing, the exception needs to be
>> chained to something.
>
> std::throw_with_nested and std::nested_exception (since C++11) do this
> with generic inheritance and polymorphism.
Both are unusable in the use case discussed above. They are meant to be
used from the catch clause of the first exception. I'm talking about an
exception that happens before the catch clause even started. Consider
the following program:
class A {
public:
~A() {
throw std::runtime_error("A failed");
}
};
int main()
{
try {
A a;
throw std::runtime_error("generated");
} catch(...) {
std::cout<<"Caught it\n";
}
return 0;
}
We never reach the catch clause, with either exceptions nor anything else.
>
> The existing solution is even better: No core language or ABI
> modification, and it works with all class types. No need for
> conformance to a generic interface, either.
I might agree, if I could, somehow, convert an in-flight exception.
Otherwise, std::nested_exception is just a distraction.
>
> C++ could make nested exception generation the default, but it would
> tend to hide the nested exceptions. Until the user adds
> nested_exception handlers, it=E2=80=99s no better than ignoring and repla=
cing
> the first exception with the second. That path wasn=E2=80=99t taken becau=
se
> it=E2=80=99s unsafe.
All irrelevant to the scenario I'm describing.
>
> Correct code handles all exceptions as *soon* and unexceptionally as
> possible, and explicitly swallows all exceptions that will be safely
> ignored.
I have issues with the word "soon", especially when used the way you
just did, to imply concurrent exceptions mean bad programming. The WHOLE
point of exceptions is that they solve the unsolvable problem: how do
you get the error from the point where we know what the error is, to the
point where we know what we should do about it. Depending on how much
effort you need to throw away in case of exception, that may not be
"soon" at all.
Take an example, an HTTP while processing the body of a request, might
decide that the request is malicious. A perfectly reasonable programming
design (IMHO) is to then decide to just close the connection and clear
all of its resources. There is no better way to do that than to throw a
malicious_connection exception, and let RAII do all the rest. Such an
exception would be caught quite a few stack frames up the ladder,
probably at the very function that initiated the fiber.
Now, consider this. Through all of this unwinding, no destructor may
throw. Even if the socket close failed due to no buffers, or writing to
logs failed because of an unavailable host. No destructor may report any
error, because if they do, the entire program terminates. Please let me
know what, in your opinion, is incorrect about this design (except the
obvious it is incorrect to throw from a destructor, as that is precisely
what I am trying to change).
Shachar
--=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/.
--------------040400050203020307050903
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html style=3D"direction: ltr;">
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
<style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
<style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
</head>
<body style=3D"direction: ltr;" bidimailui-charset-is-forced=3D"true"
bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">I'm sorry if this is a dup. I'm having
some mail server problems.<br>
<br>
On 23/04/15 05:00, David Krauss wrote:<br>
</div>
<blockquote
cite=3D"mid:B3D56CFA-5346-481B-BB1D-20A66D06D523@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 2015=E2=80=9304=E2=80=9320, at 11:20 AM, Shach=
ar Shemesh <<a
moz-do-not-send=3D"true" href=3D"mailto:shachar@lingnu.com"
class=3D"">shachar@lingnu.com</a>> wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D""><span style=3D"font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); float: none;
display: inline !important;" class=3D"">What I suggest:</span=
><br
style=3D"font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);" class=3D"">
<span style=3D"font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); float: none;
display: inline !important;" class=3D"">The simplest
solution to this problem is to simply ignore the new
exception. There are zero cases where the programmer is
worse off than she is today.</span></div>
</blockquote>
<div><br class=3D"">
</div>
<div>There are cases where terminating the program is better
than continuing it with invalid inputs or broken
preconditions.</div>
</div>
</blockquote>
The question is the opposite, I think. Are there cases where
terminating the program makes little sense? I'd argue that with RAII
properly implemented, that would be the rule, rather than the
exception.<br>
<blockquote
cite=3D"mid:B3D56CFA-5346-481B-BB1D-20A66D06D523@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D""><span style=3D"font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); float: none;
display: inline !important;" class=3D"">=C2=A0In all likeliho=
od,
the second exception is a byproduct of the first one
anyways.</span><br style=3D"font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);" class=3D"">
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>Regardless, the program isn=E2=80=99t going to handle both if =
the
first one hasn=E2=80=99t been caught when the second is thrown.</=
div>
</div>
</blockquote>
Hasn't been caught <b>yet</b>.<br>
<blockquote
cite=3D"mid:B3D56CFA-5346-481B-BB1D-20A66D06D523@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D""><span style=3D"font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); float: none;
display: inline !important;" class=3D"">An alternative
solution, but a more complicated one, is to employ
excption chaining, such as the one used by D. This has
several challenges to implement. For one thing, the
exception needs to be chained to something.</span></div>
</blockquote>
<div><br class=3D"">
</div>
<div><font class=3D"" face=3D"Courier">std::throw_with_nested</font=
>
and <font class=3D"" face=3D"Courier">std::nested_exception</font=
>=C2=A0(since
C++11) do this with generic inheritance and polymorphism.</div>
</div>
</blockquote>
Both are unusable in the use case discussed above. They are meant to
be used from the catch clause of the first exception. I'm talking
about an exception that happens before the catch clause even
started. Consider the following program:<br>
<br>
class A {<br>
public:<br>
=C2=A0=C2=A0=C2=A0 ~A() {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 throw std::runtime_error("A =
failed");<br>
=C2=A0=C2=A0=C2=A0 }<br>
};<br>
<br>
int main()<br>
{<br>
=C2=A0=C2=A0=C2=A0 try {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A a;<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 throw std::runtime_error("ge=
nerated");<br>
=C2=A0=C2=A0=C2=A0 } catch(...) {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout<<"Caught it\=
n";<br>
=C2=A0=C2=A0=C2=A0 }<br>
<br>
=C2=A0=C2=A0=C2=A0 return 0;<br>
}<br>
<br>
We never reach the catch clause, with either exceptions nor anything
else.<br>
<blockquote
cite=3D"mid:B3D56CFA-5346-481B-BB1D-20A66D06D523@gmail.com"
type=3D"cite">
<div><br>
<div>The existing solution is even better: No core language or
ABI modification, and it works with all class types. No need
for conformance to a generic interface, either.</div>
</div>
</blockquote>
I might agree, if I could, somehow, convert an in-flight exception.
Otherwise, std::nested_exception is just a distraction.<br>
<blockquote
cite=3D"mid:B3D56CFA-5346-481B-BB1D-20A66D06D523@gmail.com"
type=3D"cite"><br class=3D"">
<div class=3D"">C++=C2=A0could=C2=A0make nested exception generation =
the
default, but it would tend to hide the nested exceptions. Until
the user adds <font class=3D"" face=3D"Courier">nested_exception</f=
ont>
handlers, it=E2=80=99s no better than ignoring and replacing the fi=
rst
exception with the second. That path wasn=E2=80=99t taken because i=
t=E2=80=99s
unsafe.</div>
</blockquote>
All irrelevant to the scenario I'm describing.<br>
<blockquote
cite=3D"mid:B3D56CFA-5346-481B-BB1D-20A66D06D523@gmail.com"
type=3D"cite">
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Correct code handles all exceptions as <b>soon</b>
and unexceptionally as possible, and explicitly swallows all
exceptions that will be safely ignored.</div>
</blockquote>
I have issues with the word "soon", especially when used the way you
just did, to imply concurrent exceptions mean bad programming. The
WHOLE point of exceptions is that they solve the unsolvable problem:
how do you get the error from the point where we know what the error
is, to the point where we know what we should do about it. Depending
on how much effort you need to throw away in case of exception, that
may not be "soon" at all.<br>
<br>
Take an example, an HTTP while processing the body of a request,
might decide that the request is malicious. A perfectly reasonable
programming design (IMHO) is to then decide to just close the
connection and clear all of its resources. There is no better way to
do that than to throw a malicious_connection exception, and let RAII
do all the rest. Such an exception would be caught quite a few stack
frames up the ladder, probably at the very function that initiated
the fiber.<br>
<br>
Now, consider this. Through all of this unwinding, no destructor may
throw. Even if the socket close failed due to no buffers, or writing
to logs failed because of an unavailable host. No destructor may
report any error, because if they do, the entire program terminates.
Please let me know what, in your opinion, is incorrect about this
design (except the obvious it is incorrect to throw from a
destructor, as that is precisely what I am trying to change).<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------040400050203020307050903--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Thu, 23 Apr 2015 22:11:42 +0300
Raw View
This is a multi-part message in MIME format.
--------------030903070405020103030402
Content-Type: text/plain; charset=UTF-8
On 22/04/15 21:23, Thiago Macieira wrote:
> That's probably a much worse scenario.
>
> Imagine the following code:
>
> try {
> someCode();
> someCode2();
> } catch (...) {
> ...
> }
> someOtherCode();
>
> if someCode() throws, where would you expect execution to continue?
>
Same as today. There is nothing here that is relevant to my suggestion.
Shachar
--
---
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/.
--------------030903070405020103030402
Content-Type: text/html; charset=UTF-8
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;" bidimailui-charset-is-forced="true"
bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 22/04/15 21:23, Thiago Macieira
wrote:
</div>
<blockquote cite="mid:2297040.PxyWypmvan@tjmaciei-mobl4" type="cite">
<pre wrap="">
That's probably a much worse scenario.
Imagine the following code:
try {
someCode();
someCode2();
} catch (...) {
...
}
someOtherCode();
if someCode() throws, where would you expect execution to continue?
</pre>
</blockquote>
Same as today. There is nothing here that is relevant to my
suggestion.<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
--------------030903070405020103030402--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Thu, 23 Apr 2015 22:13:20 +0300
Raw View
This is a multi-part message in MIME format.
--------------060505060405010508080006
Content-Type: text/plain; charset=UTF-8
On 22/04/15 21:31, Johannes Schaub wrote:
> A question: Have you considered that this also changes the meaning of
> programs that don't terminate at all?
My proposal relates on the to the case where C++ today calls terminate.
>
> #include <iostream>
>
> struct Hello {
> ~Hello() {
> try {
> throw "Hello";
> }
> catch(const char *x) { std::cout << x; }
> }
> };
>
> int main() {
> try {
> Hello hello;
> throw "World";
> }
> catch(const char *y) { std::cout << y; }
> }
>
> This program prints HelloWorld, and you are going to make this print
> Hello, if I understand you correctly.
>
--
---
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/.
--------------060505060405010508080006
Content-Type: text/html; charset=UTF-8
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;" bidimailui-charset-is-forced="true"
bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 22/04/15 21:31, Johannes Schaub
wrote:
</div>
<blockquote
cite="mid:CANu6V4UpNnn5JXgYmRFC9aoXAvS89NxkJRkBxL-sf5f1ZeFT_Q@mail.gmail.com"
type="cite">
<pre wrap="">
A question: Have you considered that this also changes the meaning of
programs that don't terminate at all?</pre>
</blockquote>
My proposal relates on the to the case where C++ today calls
terminate.<br>
<blockquote
cite="mid:CANu6V4UpNnn5JXgYmRFC9aoXAvS89NxkJRkBxL-sf5f1ZeFT_Q@mail.gmail.com"
type="cite">
<pre wrap="">
#include <iostream>
struct Hello {
~Hello() {
try {
throw "Hello";
}
catch(const char *x) { std::cout << x; }
}
};
int main() {
try {
Hello hello;
throw "World";
}
catch(const char *y) { std::cout << y; }
}
This program prints HelloWorld, and you are going to make this print
Hello, if I understand you correctly.
</pre>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
--------------060505060405010508080006--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Thu, 23 Apr 2015 22:28:55 +0300
Raw View
This is a multi-part message in MIME format.
--------------060903070703030702040901
Content-Type: text/plain; charset=UTF-8
It is definitely an improvement, but still rather onerous. Please bear
in mind that it only makes sense to implement this in a destructor if
that destructor might throw. On the other hand, if the destructor calls
any other function, that function might throw as well. You end up
needing this construct for pretty much each and every destructor,
including destructors for most classes you use from libraries.
This is error prone and dangerous.
On 22/04/15 21:33, Brian Bi wrote:
> Can't you implement option 1 yourself? If you really think it is
> sensible to have the second exception ignored if it occurs during
> stack unwinding, then something like this (there are probably edge
> cases I am missing...) should work:
>
> Foo::~Foo() try {
> // body of destructor
> } catch (...) {
> if (std::uncaught_exceptions() > 0) {
> // log the exception maybe
> return; // swallow the exception
> } else {
> throw; // actually, this can be omitted; the exception
> will be automatically rethrown
> }
> }
>
Here's a nasty edge case. See if you can figure it out without the
explanation:
Foo::~Foo() {
try {
while(something) {
Bar b; // No relation to Mattel Inc.
}
} catch(...) // The rest of the catch as as with your code
}
Here's the problem. On the second iteration of the while, b's destructor
wanted to throw. Because it has the same code as us, however, it did not
throw anything. As a result, this perfectly safe throw (we would have
caught and absorbed it) did not happen, and the while loop ran more
times than it should. Your chances to reconstruct this problem with a
debugger are, not to be to specific, zero.
Shachar
--
---
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/.
--------------060903070703030702040901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html style=3D"direction: ltr;">
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
<style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
</head>
<body style=3D"direction: ltr;" bidimailui-charset-is-forced=3D"true"
bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">It is definitely an improvement, but
still rather onerous. Please bear in mind that it only makes sense
to implement this in a destructor if that destructor might throw.
On the other hand, if the destructor calls any other function,
that function might throw as well. You end up needing this
construct for pretty much each and every destructor, including
destructors for most classes you use from libraries.<br>
<br>
This is error prone and dangerous.<br>
<br>
On 22/04/15 21:33, Brian Bi wrote:<br>
</div>
<blockquote
cite=3D"mid:CAMmfjbOOFiFbKX9y=3Dtc1+XOPBaKK+drYH31pZOQ4RLRqr_4aGw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">Can't you implement option 1 yourself? If you
really think it is sensible to have the second exception ignored
if it occurs during stack unwinding, then something like this
(there are probably edge cases I am missing...) should work:
<div><br>
</div>
<div>=C2=A0 =C2=A0 Foo::~Foo() try {</div>
<div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 // body of destructor</div>
<div>=C2=A0 =C2=A0=C2=A0} catch (...) {</div>
<div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 if (std::uncaught_exceptions(=
) > 0) {</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // log the exception=
maybe</div>
<div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 return; //=
swallow the exception</div>
<div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 } else {</div>
<div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 throw; // =
actually, this can be omitted; the
exception will be automatically rethrown</div>
</div>
</blockquote>
<blockquote
cite=3D"mid:CAMmfjbOOFiFbKX9y=3Dtc1+XOPBaKK+drYH31pZOQ4RLRqr_4aGw@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 }</div>
<div>=C2=A0 =C2=A0=C2=A0}</div>
</div>
<div class=3D"gmail_extra"><br>
</div>
</blockquote>
Here's a nasty edge case. See if you can figure it out without the
explanation:<br>
<br>
Foo::~Foo() {<br>
=C2=A0=C2=A0=C2=A0 try {<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 while(something) {<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Bar b; // No r=
elation to Mattel Inc.<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 } catch(...) // The rest of the catch as as with you=
r code<br>
}<br>
<br>
Here's the problem. On the second iteration of the while, b's
destructor wanted to throw. Because it has the same code as us,
however, it did not throw anything. As a result, this perfectly safe
throw (we would have caught and absorbed it) did not happen, and the
while loop ran more times than it should. Your chances to
reconstruct this problem with a debugger are, not to be to specific,
zero.<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------060903070703030702040901--
.
Author: "T. C." <rs2740@gmail.com>
Date: Thu, 23 Apr 2015 23:42:47 -0700 (PDT)
Raw View
------=_Part_584_1101929017.1429857767295
Content-Type: multipart/alternative;
boundary="----=_Part_585_222016991.1429857767295"
------=_Part_585_222016991.1429857767295
Content-Type: text/plain; charset=UTF-8
On Thursday, April 23, 2015 at 3:28:57 PM UTC-4, Shachar Shemesh wrote:
>
>
> On 22/04/15 21:33, Brian Bi wrote:
>
> Can't you implement option 1 yourself? If you really think it is sensible
> to have the second exception ignored if it occurs during stack unwinding,
> then something like this (there are probably edge cases I am missing...)
> should work:
>
> Foo::~Foo() try {
> // body of destructor
> } catch (...) {
> if (std::uncaught_exceptions() > 0) {
> // log the exception maybe
> return; // swallow the exception
> } else {
> throw; // actually, this can be omitted; the exception will be
> automatically rethrown
>
> }
> }
>
> Here's a nasty edge case. See if you can figure it out without the
> explanation:
>
> Foo::~Foo() {
> try {
> while(something) {
> Bar b; // No relation to Mattel Inc.
> }
> } catch(...) // The rest of the catch as as with your code
> }
>
> Here's the problem. On the second iteration of the while, b's destructor
> wanted to throw. Because it has the same code as us, however, it did not
> throw anything. As a result, this perfectly safe throw (we would have
> caught and absorbed it) did not happen, and the while loop ran more times
> than it should. Your chances to reconstruct this problem with a debugger
> are, not to be to specific, zero.
>
> Shachar
>
This is exactly why uncaught_exceptions() was added, and
uncaught_exception() deprecated.
--
---
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_585_222016991.1429857767295
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div><br><br>On Thursday, April 23, 2015 at=
3:28:57 PM UTC-4, Shachar Shemesh wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div style=3D"direction:ltr" bgcolor=3D"#FFFFFF" text=3D"#000000=
"><div>
<br>
On 22/04/15 21:33, Brian Bi wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">Can't you implement option 1 yourself? If you
really think it is sensible to have the second exception ignored
if it occurs during stack unwinding, then something like this
(there are probably edge cases I am missing...) should work:
<div><br>
</div>
<div> Foo::~Foo() try {</div>
<div> // body of destructor</div>
<div> } catch (...) {</div>
<div> if (std::uncaught_exceptions(=
) > 0) {</div>
<div> // log the exception=
maybe</div>
<div> return; //=
swallow the exception</div>
<div> } else {</div>
<div> throw; // =
actually, this can be omitted; the
exception will be automatically rethrown</div>
</div>
</blockquote>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div> }</div>
<div> }</div>
</div>
<div><br>
</div>
</blockquote>
Here's a nasty edge case. See if you can figure it out without the
explanation:<br>
<br>
Foo::~Foo() {<br>
try {<br>
while(something) {<br>
Bar b; // No r=
elation to Mattel Inc.<br>
}<br>
} catch(...) // The rest of the catch as as with you=
r code<br>
}<br>
<br>
Here's the problem. On the second iteration of the while, b's
destructor wanted to throw. Because it has the same code as us,
however, it did not throw anything. As a result, this perfectly safe
throw (we would have caught and absorbed it) did not happen, and the
while loop ran more times than it should. Your chances to
reconstruct this problem with a debugger are, not to be to specific,
zero.<br>
<br>
Shachar<br></div></blockquote><div><br></div><div><br></div><div>This i=
s exactly why uncaught_exceptions() was added, and uncaught_exception() dep=
recated.</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" 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_585_222016991.1429857767295--
------=_Part_584_1101929017.1429857767295--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 24 Apr 2015 17:06:30 +0800
Raw View
--Apple-Mail=_00293F52-4A85-4293-8415-E33AC8194C31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9324, at 3:09 AM, Shachar Shemesh <shachar@lingn=
u.com> wrote:
>> Regardless, the program isn=E2=80=99t going to handle both if the first =
one hasn=E2=80=99t been caught when the second is thrown.
> Hasn't been caught yet.
When will it be caught? I don=E2=80=99t see where you=E2=80=99ve proposed t=
o have two exceptions unwinding simultaneously.
You mentioned the chained exception facility in D. I=E2=80=99m not familiar=
with that language, and I couldn=E2=80=99t find anything online about thro=
wing destructors or automatic chaining/nesting. Perhaps you can provide a r=
eference.
> Take an example, an HTTP while processing the body of a request, might de=
cide that the request is malicious. A perfectly reasonable programming desi=
gn (IMHO) is to then decide to just close the connection and clear all of i=
ts resources. There is no better way to do that than to throw a malicious_c=
onnection exception, and let RAII do all the rest. Such an exception would =
be caught quite a few stack frames up the ladder, probably at the very func=
tion that initiated the fiber.
>=20
> Now, consider this. Through all of this unwinding, no destructor may thro=
w. Even if the socket close failed due to no buffers, or writing to logs fa=
iled because of an unavailable host. No destructor may report any error, be=
cause if they do, the entire program terminates. Please let me know what, i=
n your opinion, is incorrect about this design (except the obvious it is in=
correct to throw from a destructor, as that is precisely what I am trying t=
o change).
There are indeed rough edges around exceptions, but:
1. Malicious connections should be torn down ASAP, no need to do things gra=
cefully. Most socket libraries provide a facility for this. Anyway, resourc=
es for graceful shutdown should be pre-allocated, and if they=E2=80=99re no=
t, the connection must be abandoned as a fallback.
2. If logging can throw, and you do it directly from destructors, then you=
=E2=80=99re making a conscious decision that failure of the logging system =
may terminate the program.
2a. Otherwise, you may write logs to a local buffer and let a different thr=
ead or outer loop flush that to the logging host.
2b. Or, just swallow logging exceptions within destructors. This is the mor=
e popular choice. (The default behavior of iostreams goes one step further:=
badbit will disable logging completely until you acknowledge the problem.)
3. How do you suggest to actually handle simultaneous exceptions? You menti=
oned to =E2=80=9Cconvert an in-flight exception=E2=80=9D before it=E2=80=99=
s caught, but do you really want to replace the malicious_connection error =
with a bad_alloc or ios::failure, and then re-throw it from the context of =
the logging or memory exception handler? The order of handlers on the stack=
is dictated by high-level program architecture, and it=E2=80=99s not even =
clear which arrangement is correct.
Just being imaginative, one possibility is extend unwinding to work on a se=
t of exceptions. When a handler is found matching any exception, remove it =
from the set. When the handler exits, normally or abnormally, resume unwind=
ing with the remaining set plus any new exceptions being unwound. However, =
this seems like a theoretical solution in search of a problem.
A more sensible way to handle low-level exceptions is to have a protocol fo=
r offloading the exception-unsafe behavior from the destructor into an asyn=
chronous process or coroutine. If a destructor is unfortunate enough to rea=
lize that a webpage can=E2=80=99t be served, don=E2=80=99t force it to try =
to synchronously serve an error page. Enqueue some minimal information so t=
he rest of the server can deal with the situation =E2=80=9Csoon,=E2=80=9D b=
ut perhaps not immediately.
As for the immediate recourse, C++17 will include a feature to allow destru=
ctors to decide whether or not to throw. When not throwing, you can record =
exceptions into std::exception_ptr objects, perhaps in thread-local storage=
.. Inspect and re-throw those pointers as appropriate. Such technique should=
be more expressive and intuitive than built-in chaining could ever be.
--=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/.
--Apple-Mail=_00293F52-4A85-4293-8415-E33AC8194C31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9324, at 3:09 AM, Shachar Shemesh <<a href=3D"mailto:shachar@ling=
nu.com" class=3D"">shachar@lingnu.com</a>> wrote:</div></blockquote><blo=
ckquote type=3D"cite" class=3D""><blockquote cite=3D"mid:B3D56CFA-5346-481B=
-BB1D-20A66D06D523@gmail.com" type=3D"cite" style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-co=
lor: rgb(255, 255, 255);" class=3D""><div class=3D"">Regardless, the progra=
m isn=E2=80=99t going to handle both if the first one hasn=E2=80=99t been c=
aught when the second is thrown.</div></blockquote><span style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
background-color: rgb(255, 255, 255); float: none; display: inline !importa=
nt;" class=3D"">Hasn't been caught<span class=3D"Apple-converted-space">&nb=
sp;</span></span><b style=3D"font-family: Helvetica; font-size: 12px; font-=
style: normal; font-variant: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px; background-color: rgb(255, 255, 255);" class=3D"">yet</b><=
span style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; d=
isplay: inline !important;" class=3D"">.</span><br style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; backgr=
ound-color: rgb(255, 255, 255);" class=3D""></blockquote><div><br class=3D"=
"></div><div>When will it be caught? I don=E2=80=99t see where you=E2=80=99=
ve proposed to have two exceptions unwinding simultaneously.</div><div><br =
class=3D""></div><div>You mentioned the chained exception facility in D. I=
=E2=80=99m not familiar with that language, and I couldn=E2=80=99t find any=
thing online about throwing destructors or automatic chaining/nesting. Perh=
aps you can provide a reference.</div><div><br class=3D""></div><blockquote=
type=3D"cite" class=3D""><span style=3D"background-color: rgb(255, 255, 25=
5);" class=3D"">Take an example, an HTTP while processing the body of a req=
uest, might decide that the request is malicious. A perfectly reasonable pr=
ogramming design (IMHO) is to then decide to just close the connection and =
clear all of its resources. There is no better way to do that than to throw=
a malicious_connection exception, and let RAII do all the rest. Such an ex=
ception would be caught quite a few stack frames up the ladder, probably at=
the very function that initiated the fiber.</span></blockquote><blockquote=
type=3D"cite" class=3D""><br style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, =
255, 255);" class=3D""><span style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 2=
55, 255); float: none; display: inline !important;" class=3D"">Now, conside=
r this. Through all of this unwinding, no destructor may throw. Even if the=
socket close failed due to no buffers, or writing to logs failed because o=
f an unavailable host. No destructor may report any error, because if they =
do, the entire program terminates. Please let me know what, in your opinion=
, is incorrect about this design (except the obvious it is incorrect to thr=
ow from a destructor, as that is precisely what I am trying to change).</sp=
an><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tra=
nsform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit=
-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=3D"">=
</blockquote><div><br class=3D""></div><div>There are indeed rough edges ar=
ound exceptions, but:</div><div><br class=3D""></div><div>1. Malicious conn=
ections should be torn down ASAP, no need to do things gracefully. Most soc=
ket libraries provide a facility for this. Anyway, resources for graceful s=
hutdown should be pre-allocated, and if they=E2=80=99re not, the connection=
must be abandoned as a fallback.</div><div><br class=3D""></div><div>2. If=
logging can throw, and you do it directly from destructors, then you=E2=80=
=99re making a conscious decision that failure of the logging system may te=
rminate the program.</div><div>2a. Otherwise, you may write logs to a local=
buffer and let a different thread or outer loop flush that to the logging =
host.</div><div>2b. Or, just swallow logging exceptions within destructors.=
This is the more popular choice. (The default behavior of iostreams goes o=
ne step further: <font face=3D"Courier" class=3D"">badbit</font> will disab=
le logging completely until you acknowledge the problem.)</div><div><br cla=
ss=3D""></div><div>3. How do you suggest to actually handle simultaneous ex=
ceptions? You mentioned to =E2=80=9Cconvert an in-flight exception=E2=80=9D=
before it=E2=80=99s caught, but do you really want to replace the <font fa=
ce=3D"Courier" class=3D"">malicious_connection</font> error with a <font fa=
ce=3D"Courier" class=3D"">bad_alloc</font> or <font face=3D"Courier" class=
=3D"">ios::failure</font>, and then re-throw it from the context of the log=
ging or memory exception handler? The order of handlers on the stack is dic=
tated by high-level program architecture, and it=E2=80=99s not even clear w=
hich arrangement is correct.</div><div><br class=3D""></div><div>Just being=
imaginative, one possibility is extend unwinding to work on a set of excep=
tions. When a handler is found matching any exception, remove it from the s=
et. When the handler exits, normally or abnormally, resume unwinding with t=
he remaining set plus any new exceptions being unwound. However, this seems=
like a theoretical solution in search of a problem.</div><div><br class=3D=
""></div><div>A more sensible way to handle low-level exceptions is to have=
a protocol for offloading the exception-unsafe behavior from the destructo=
r into an asynchronous process or coroutine. If a destructor is unfortunate=
enough to realize that a webpage can=E2=80=99t be served, don=E2=80=99t fo=
rce it to try to synchronously serve an error page. Enqueue some minimal in=
formation so the rest of the server can deal with the situation =E2=80=9Cso=
on,=E2=80=9D but perhaps not immediately.</div><div><br class=3D""></div><d=
iv>As for the immediate recourse, C++17 will include a feature to allow des=
tructors to decide whether or not to throw. When not throwing, you can reco=
rd exceptions into <font face=3D"Courier" class=3D"">std::exception_pt=
r</font> objects, perhaps in thread-local storage. Inspect and re-throw tho=
se pointers as appropriate. Such technique should be more expressive and in=
tuitive than built-in chaining could ever be.</div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_00293F52-4A85-4293-8415-E33AC8194C31--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Fri, 24 Apr 2015 13:20:31 +0300
Raw View
This is a multi-part message in MIME format.
--------------000905090909040402080800
Content-Type: text/plain; charset=UTF-8
On 24/04/15 09:42, T. C. wrote:
> This is exactly why uncaught_exceptions() was added, and
> uncaught_exception() deprecated.
Except I fail to see how it makes things any better.
Can you elaborate using code?
Shachar
--
---
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/.
--------------000905090909040402080800
Content-Type: text/html; charset=UTF-8
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;" bidimailui-charset-is-forced="true"
bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 24/04/15 09:42, T. C. wrote:<br>
</div>
<blockquote
cite="mid:c1590096-697e-44c9-a99d-7b07a74589bc@isocpp.org"
type="cite">This is exactly why uncaught_exceptions() was added,
and uncaught_exception() deprecated.</blockquote>
Except I fail to see how it makes things any better.<br>
<br>
Can you elaborate using code?<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
--------------000905090909040402080800--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Fri, 24 Apr 2015 14:04:21 +0300
Raw View
This is a multi-part message in MIME format.
--------------020204060306080503080805
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 24/04/15 12:06, David Krauss wrote:
>
>
> You mentioned the chained exception facility in D. I=E2=80=99m not famili=
ar
> with that language, and I couldn=E2=80=99t find anything online about thr=
owing
> destructors or automatic chaining/nesting. Perhaps you can provide a
> reference.
Some good news and some bad. This is described quite nicely in section
9.5, titled "Collateral Exceptions" of "The D Programming Language".
Unfortunately, the book is not available online (at least, not for free).
In a nutshell:
* You can only throw classes that derive from Throwable.
* Thrownable has a field, "next", that can be queried by catch handler
* In any situation where, in C++, the program would terminate, in D
the new exception is added to the "next" field of the exception
currently last in the chain
* The catch can query the next header to scan the list and decide
whether they want to do something about the collateral exceptions or
not.
>
> There are indeed rough edges around exceptions, but:
>
> 1. Malicious connections should be torn down ASAP, no need to do
> things gracefully.
Huh? This statement is so wrong on so many levels:
* ASAP is as soon as you can detect it is malicious. You cannot detect
malicious body until you've parsed the request, the headers, looked
up the resource etc. In other words, "soon" is a very relative term
in this case.
* No need to do things gracefully? Seriously? What about the thousands
of other connections this server is handling? Shouldn't they get a
chance to use the memory you've allocated for this connection?
May I remind you that exceptions are the only case where C++ potentially
does dynamic heap allocations without you explicitly asking for it?
> Anyway, resources for graceful shutdown should be pre-allocated, and
> if they=E2=80=99re not, the connection must be abandoned as a fallback.
Abandoning the connection is precisely what I'm trying to do here.
>
> 2. If logging can throw, and you do it directly from destructors, then
> you=E2=80=99re making a conscious decision that failure of the logging sy=
stem
> may terminate the program.
You're begging the question
<https://en.wikipedia.org/wiki/Begging_the_question>. The only reason
you're equating the two is because that's how C++ does things. But that
is precisely what I'm urging to change. You could log, have log failures
throw and do it from a destructor without risking program termination if
my proposal is accepted. In fact, you've just validated the necessity.
Thank you :-)
2a and 2b are just workarounds to the problem C++ is dumping at my door.
They might be a good idea anyway (debatable), but my point is that C++
should not force me to use them.
>
> 3. How do you suggest to actually handle simultaneous exceptions? You
> mentioned to =E2=80=9Cconvert an in-flight exception=E2=80=9D before it=
=E2=80=99s caught, but
> do you really want to replace the malicious_connection error with a
> bad_alloc or ios::failure, and then re-throw it from the context of
> the logging or memory exception handler? The order of handlers on the
> stack is dictated by high-level program architecture, and it=E2=80=99s no=
t
> even clear which arrangement is correct.
The primary exception, i.e. - the one that triggered first, should be
the one the catch clauses should compare against. The rest should
piggyback on it, e.g., the D way, by means of a singly linked list.
>
> Just being imaginative, one possibility is extend unwinding to work on
> a set of exceptions. When a handler is found matching any exception,
> remove it from the set. When the handler exits, normally or
> abnormally, resume unwinding with the remaining set plus any new
> exceptions being unwound. However, this seems like a theoretical
> solution in search of a problem.
>
> A more sensible way to handle low-level exceptions is to have a
> protocol for offloading the exception-unsafe behavior from the
> destructor into an asynchronous process or coroutine. If a destructor
> is unfortunate enough to realize that a webpage can=E2=80=99t be served, =
don=E2=80=99t
> force it to try to synchronously serve an error page. Enqueue some
> minimal information so the rest of the server can deal with the
> situation =E2=80=9Csoon,=E2=80=9D but perhaps not immediately.
Again, a workaround. Not a very practical one, too. Most high
performance web servers utilize micro-threading, which is not something
C++ is even aware of.
In particular, the code I have in mind when judging your suggested
alternatives is ghost, Akamai's proxy server. It drives 25% of the
Internet's web traffic, and I'm simply not seeing it doing so the way
you describe it should.
>
> As for the immediate recourse, C++17 will include a feature to allow
> destructors to decide whether or not to throw. When not throwing, you
> can record exceptions into std::exception_ptr objects, perhaps in
> thread-local storage. Inspect and re-throw those pointers as
> appropriate. Such technique should be more expressive and intuitive
> than built-in chaining could ever be.
Maybe, but see my reply to Brian Bi, and later to T.C., for why what
C++17 isn't good enough (IMHO).
Shachar
--=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/.
--------------020204060306080503080805
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html style=3D"direction: ltr;">
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
<style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
</head>
<body style=3D"direction: ltr;" bidimailui-charset-is-forced=3D"true"
bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 24/04/15 12:06, David Krauss wrote:<b=
r>
</div>
<blockquote
cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<br class=3D"">
<div><br>
<div>You mentioned the chained exception facility in D. I=E2=80=99m=
not
familiar with that language, and I couldn=E2=80=99t find anything
online about throwing destructors or automatic
chaining/nesting. Perhaps you can provide a reference.</div>
</div>
</blockquote>
Some good news and some bad. This is described quite nicely in
section 9.5, titled "Collateral Exceptions" of "The D Programming
Language". Unfortunately, the book is not available online (at
least, not for free).<br>
<br>
In a nutshell:<br>
<ul>
<li>You can only throw classes that derive from Throwable.</li>
<li>Thrownable has a field, "next", that can be queried by catch
handler</li>
<li>In any situation where, in C++, the program would terminate,
in D the new exception is added to the "next" field of the
exception currently last in the chain</li>
<li>The catch can query the next header to scan the list and
decide whether they want to do something about the collateral
exceptions or not.<br>
</li>
</ul>
<blockquote
cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com"
type=3D"cite">
<div><br>
<div>There are indeed rough edges around exceptions, but:</div>
<div><br class=3D"">
</div>
<div>1. Malicious connections should be torn down ASAP, no need
to do things gracefully.</div>
</div>
</blockquote>
Huh? This statement is so wrong on so many levels:<br>
<ul>
<li>ASAP is as soon as you can detect it is malicious. You cannot
detect malicious body until you've parsed the request, the
headers, looked up the resource etc. In other words, "soon" is a
very relative term in this case.</li>
<li>No need to do things gracefully? Seriously? What about the
thousands of other connections this server is handling?
Shouldn't they get a chance to use the memory you've allocated
for this connection?</li>
</ul>
<p>May I remind you that exceptions are the only case where C++
potentially does dynamic heap allocations without you explicitly
asking for it?<br>
</p>
<blockquote
cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com"
type=3D"cite">
<div>
<div>Anyway, resources for graceful shutdown should be
pre-allocated, and if they=E2=80=99re not, the connection must be
abandoned as a fallback.</div>
</div>
</blockquote>
Abandoning the connection is precisely what I'm trying to do here.<br>
<blockquote
cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com"
type=3D"cite">
<div>
<div><br class=3D"">
</div>
<div>2. If logging can throw, and you do it directly from
destructors, then you=E2=80=99re making a conscious decision that
failure of the logging system may terminate the program.</div>
</div>
</blockquote>
You're <a href=3D"https://en.wikipedia.org/wiki/Begging_the_question">b=
egging
the question</a>. The only reason you're equating the two is
because that's how C++ does things. But that is precisely what I'm
urging to change. You could log, have log failures throw and do it
from a destructor without risking program termination if my proposal
is accepted. In fact, you've just validated the necessity. Thank you
:-)<br>
<br>
2a and 2b are just workarounds to the problem C++ is dumping at my
door. They might be a good idea anyway (debatable), but my point is
that C++ should not force me to use them.<br>
<blockquote
cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com"
type=3D"cite">
<div><br>
<div>3. How do you suggest to actually handle simultaneous
exceptions? You mentioned to =E2=80=9Cconvert an in-flight except=
ion=E2=80=9D
before it=E2=80=99s caught, but do you really want to replace the=
<font
class=3D"" face=3D"Courier">malicious_connection</font> error
with a <font class=3D"" face=3D"Courier">bad_alloc</font> or <fon=
t
class=3D"" face=3D"Courier">ios::failure</font>, and then
re-throw it from the context of the logging or memory
exception handler? The order of handlers on the stack is
dictated by high-level program architecture, and it=E2=80=99s not=
even
clear which arrangement is correct.</div>
</div>
</blockquote>
The primary exception, i.e. - the one that triggered first, should
be the one the catch clauses should compare against. The rest should
piggyback on it, e.g., the D way, by means of a singly linked list.<br>
<blockquote
cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com"
type=3D"cite">
<div>
<div><br class=3D"">
</div>
<div>Just being imaginative, one possibility is extend unwinding
to work on a set of exceptions. When a handler is found
matching any exception, remove it from the set. When the
handler exits, normally or abnormally, resume unwinding with
the remaining set plus any new exceptions being unwound.
However, this seems like a theoretical solution in search of a
problem.</div>
<div><br class=3D"">
</div>
<div>A more sensible way to handle low-level exceptions is to
have a protocol for offloading the exception-unsafe behavior
from the destructor into an asynchronous process or coroutine.
If a destructor is unfortunate enough to realize that a
webpage can=E2=80=99t be served, don=E2=80=99t force it to try to
synchronously serve an error page. Enqueue some minimal
information so the rest of the server can deal with the
situation =E2=80=9Csoon,=E2=80=9D but perhaps not immediately.</d=
iv>
</div>
</blockquote>
Again, a workaround. Not a very practical one, too. Most high
performance web servers utilize micro-threading, which is not
something C++ is even aware of.<br>
<br>
In particular, the code I have in mind when judging your suggested
alternatives is ghost, Akamai's proxy server. It drives 25% of the
Internet's web traffic, and I'm simply not seeing it doing so the
way you describe it should.<br>
<blockquote
cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com"
type=3D"cite">
<div>
<div><br class=3D"">
</div>
<div>As for the immediate recourse, C++17 will include a feature
to allow destructors to decide whether or not to throw. When
not throwing, you can record exceptions into=C2=A0<font class=3D"=
"
face=3D"Courier">std::exception_ptr</font> objects, perhaps in
thread-local storage. Inspect and re-throw those pointers as
appropriate. Such technique should be more expressive and
intuitive than built-in chaining could ever be.</div>
</div>
</blockquote>
Maybe, but see my reply to Brian Bi, and later to T.C., for why what
C++17 isn't good enough (IMHO).<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------020204060306080503080805--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Fri, 24 Apr 2015 15:51:48 +0300
Raw View
This is a multi-part message in MIME format.
--------------060300010801030800090605
Content-Type: text/plain; charset=UTF-8
On 24/04/15 14:04, Shachar Shemesh wrote:
>
> In particular, the code I have in mind when judging your suggested
> alternatives is ghost, Akamai's proxy server. It drives 25% of the
> Internet's web traffic, and I'm simply not seeing it doing so the way
> you describe it should.
I'd like to clarify that the opinions presented by me, both in this
thread and elsewhere, are mine and mine alone. They represent neither
the opinions of my current employer nor those of Akamai, for whom I no
longer work.
Shachar
--
---
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/.
--------------060300010801030800090605
Content-Type: text/html; charset=UTF-8
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;" bidimailui-charset-is-forced="true"
bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 24/04/15 14:04, Shachar Shemesh
wrote:<br>
</div>
<blockquote cite="mid:553A2335.7080200@lingnu.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; }</style><br>
In particular, the code I have in mind when judging your suggested
alternatives is ghost, Akamai's proxy server. It drives 25% of the
Internet's web traffic, and I'm simply not seeing it doing so the
way you describe it should.<br>
</blockquote>
I'd like to clarify that the opinions presented by me, both in this
thread and elsewhere, are mine and mine alone. They represent
neither the opinions of my current employer nor those of Akamai, for
whom I no longer work.<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
--------------060300010801030800090605--
.
Author: "T. C." <rs2740@gmail.com>
Date: Fri, 24 Apr 2015 08:24:07 -0700 (PDT)
Raw View
------=_Part_707_1983652457.1429889047722
Content-Type: multipart/alternative;
boundary="----=_Part_708_1710708771.1429889047722"
------=_Part_708_1710708771.1429889047722
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, April 24, 2015 at 6:20:34 AM UTC-4, Shachar Shemesh wrote:
>
> On 24/04/15 09:42, T. C. wrote:
> =20
> This is exactly why uncaught_exceptions() was added, and=20
> uncaught_exception() deprecated.
>
> Except I fail to see how it makes things any better.
>
> Can you elaborate using code?
>
> Shachar
>
To quote http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf:
A type that wants to know whether its destructor is being run to unwind=20
> this object can query uncaught_exceptions in its constructor and store th=
e=20
> result, then query uncaught_exceptions again in its destructor; if the=20
> result is different, then this destructor is being invoked as part of sta=
ck=20
> unwinding due to a new exception that was thrown later than the object=E2=
=80=99s=20
> construction.
--=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_708_1710708771.1429889047722
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, April 24, 2015 at 6:20:34 AM UTC-4, Sha=
char Shemesh wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
=20
<div style=3D"direction:ltr" bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>On 24/04/15 09:42, T. C. wrote:<br>
</div>
<blockquote type=3D"cite">This is exactly why uncaught_exceptions() was=
added,
and uncaught_exception() deprecated.</blockquote>
Except I fail to see how it makes things any better.<br>
<br>
Can you elaborate using code?<br>
<br>
Shachar<br></div></blockquote><div><br></div><div>To quote http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf:</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">A type that wants to know whether its destruct=
or is being run to unwind this object can query
uncaught_exceptions in its constructor and store the result, then query unc=
aught_exceptions again
in its destructor; if the result is different, then this destructor is bein=
g invoked as part of stack unwinding
due to a new exception that was thrown later than the object=E2=80=99s cons=
truction.</blockquote><div><br></div><div><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" 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_708_1710708771.1429889047722--
------=_Part_707_1983652457.1429889047722--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Fri, 24 Apr 2015 18:39:20 +0300
Raw View
This is a multi-part message in MIME format.
--------------040307030004020708050808
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 24/04/15 18:24, T. C. wrote:
>
>
> On Friday, April 24, 2015 at 6:20:34 AM UTC-4, Shachar Shemesh wrote:
>
> On 24/04/15 09:42, T. C. wrote:
>> This is exactly why uncaught_exceptions() was added, and
>> uncaught_exception() deprecated.
> Except I fail to see how it makes things any better.
>
> Can you elaborate using code?
>
> Shachar
>
>
> To quote
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf:
>
> A type that wants to know whether its destructor is being run to
> unwind this object can query uncaught_exceptions in its
> constructor and store the result, then query uncaught_exceptions
> again in its destructor; if the result is different, then this
> destructor is being invoked as part of stack unwinding due to a
> new exception that was thrown later than the object=E2=80=99s constru=
ction.
>
>
>
I'll point out that I believe there are still some use cases where this
isn't good enough. That's not my main objection, however.
What I'm failing to see is how is this better than what I'm suggesting?
This means that a whole bunch of classes now need to store an extra int
for a use case that will hardly ever come to pass. This, to me, seems
simply wrong.
The whole point of exceptions is that you don't pay for them in the good
path. That's the principle that caused cfont to be abandoned. It's the
reason the compiler often produces two versions of the same code when
exceptions are employed. It is one of the main founding principles of
exception handling.
This principle is clearly violated here. I'm paying both in code and in
storage for a feature that I will need only in the bad path, and worse,
only in rare cases in the bad path.
That seems simply wrong to me.
Shachar
--=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/.
--------------040307030004020708050808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html style=3D"direction: ltr;">
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
<style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
</head>
<body style=3D"direction: ltr;" bidimailui-charset-is-forced=3D"true"
bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 24/04/15 18:24, T. C. wrote:<br>
</div>
<blockquote
cite=3D"mid:c5541575-9452-41ca-8028-fdad951797a5@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Friday, April 24, 2015 at 6:20:34 AM UTC-4, Shachar Shemesh
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div style=3D"direction:ltr" bgcolor=3D"#FFFFFF" text=3D"#000000"=
>
<div>On 24/04/15 09:42, T. C. wrote:<br>
</div>
<blockquote type=3D"cite">This is exactly why
uncaught_exceptions() was added, and uncaught_exception()
deprecated.</blockquote>
Except I fail to see how it makes things any better.<br>
<br>
Can you elaborate using code?<br>
<br>
Shachar<br>
</div>
</blockquote>
<div><br>
</div>
<div>To quote
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf">http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2014/n4152.pdf</a>:</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">A
type that wants to know whether its destructor is being run to
unwind this object can query
uncaught_exceptions in its constructor and store the result,
then query uncaught_exceptions again
in its destructor; if the result is different, then this
destructor is being invoked as part of stack unwinding
due to a new exception that was thrown later than the object=E2=
=80=99s
construction.</blockquote>
<div><br>
</div>
<br>
</div>
</blockquote>
I'll point out that I believe there are still some use cases where
this isn't good enough. That's not my main objection, however.<br>
<br>
What I'm failing to see is how is this better than what I'm
suggesting? This means that a whole bunch of classes now need to
store an extra int for a use case that will hardly ever come to
pass. This, to me, seems simply wrong.<br>
<br>
The whole point of exceptions is that you don't pay for them in the
good path. That's the principle that caused cfont to be abandoned.
It's the reason the compiler often produces two versions of the same
code when exceptions are employed. It is one of the main founding
principles of exception handling.<br>
<br>
This principle is clearly violated here. I'm paying both in code and
in storage for a feature that I will need only in the bad path, and
worse, only in rare cases in the bad path.<br>
<br>
That seems simply wrong to me.<br>
<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------040307030004020708050808--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 24 Apr 2015 09:11:12 -0700
Raw View
On Thursday 23 April 2015 22:11:42 Shachar Shemesh wrote:
> On 22/04/15 21:23, Thiago Macieira wrote:
> > That's probably a much worse scenario.
> >
> > Imagine the following code:
> > try {
> >
> > someCode();
> > someCode2();
> >
> > } catch (...) {
> >
> > ...
> >
> > }
> > someOtherCode();
> >
> > if someCode() throws, where would you expect execution to continue?
>
> Same as today. There is nothing here that is relevant to my suggestion.
If it is the same as today, then the exception isn't ignored. That is what you
had suggested.
--
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 25 Apr 2015 05:21:53 +0800
Raw View
--Apple-Mail=_352FF47D-CF7B-478C-8032-D59285B29CD3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9324, at 7:04 PM, Shachar Shemesh <shachar@lingn=
u.com> wrote:
>=20
> In any situation where, in C++, the program would terminate, in D the new=
exception is added to the "next" field of the exception currently last in =
the chain
So the would-be offending exception doesn=E2=80=99t get thrown. This is eff=
ectively the same as having a thread-local list of exceptions that couldn=
=E2=80=99t be processed, which is within the scope of my exception_ptr sugg=
estion.
> The catch can query the next header to scan the list and decide whether t=
hey want to do something about the collateral exceptions or not.
And if it doesn=E2=80=99t, the exceptions never get handled. Not a good pol=
icy to bake into the core language.
>> 1. Malicious connections should be torn down ASAP, no need to do things =
gracefully.
> Huh? This statement is so wrong on so many levels:
> ASAP is as soon as you can detect it is malicious. You cannot detect mali=
cious body until you've parsed the request, the headers, looked up the reso=
urce etc. In other words, "soon" is a very relative term in this case.
> No need to do things gracefully? Seriously? What about the thousands of o=
ther connections this server is handling? Shouldn't they get a chance to us=
e the memory you've allocated for this connection?
I was only speaking in terms of sockets, once the problem is detected. You =
shouldn=E2=80=99t need to buffer any additional data to gracefully end a ma=
licious user=E2=80=99s TCP connection, which is what you seemed to be refer=
ring to.
> May I remind you that exceptions are the only case where C++ potentially =
does dynamic heap allocations without you explicitly asking for it?
Exception objects are usually allocated within a reserved arena. Heap alloc=
ation doesn=E2=80=99t sound like a conforming implementation of exceptions,=
at least not for bad_alloc.
>> 2. If logging can throw, and you do it directly from destructors, then y=
ou=E2=80=99re making a conscious decision that failure of the logging syste=
m may terminate the program.
> You're begging the question <https://en.wikipedia.org/wiki/Begging_the_qu=
estion>. The only reason you're equating the two is because that's how C++ =
does things.
When a destructor throws, not only does unwinding get a headache, but the o=
bject hasn=E2=80=99t been destroyed. A destructor that fails to free resour=
ces when the log facility is unavailable isn=E2=80=99t a very good one.
Exception-free destructors are the foundation of RTTI. C++ has good reason =
for doing things the way it does.
> But that is precisely what I'm urging to change. You could log, have log =
failures throw and do it from a destructor without risking program terminat=
ion if my proposal is accepted. In fact, you've just validated the necessit=
y. Thank you :-)
You still haven=E2=80=99t described how any of these exceptions will actual=
ly get handled.
> 2a and 2b are just workarounds to the problem C++ is dumping at my door. =
They might be a good idea anyway (debatable), but my point is that C++ shou=
ld not force me to use them.
Please provide a self-consistent outline of some alternative, including the=
restrictions on the malicious_connection handler. Is it allowed to attempt=
allocation or logging if it runs while there are already outstanding bad_a=
lloc or ios::failure exceptions? Under what conditions does it re-throw the=
nested exception?
>> A more sensible way to handle low-level exceptions is to have a protocol=
for offloading the exception-unsafe behavior from the destructor into an a=
synchronous process or coroutine. If a destructor is unfortunate enough to =
realize that a webpage can=E2=80=99t be served, don=E2=80=99t force it to t=
ry to synchronously serve an error page. Enqueue some minimal information s=
o the rest of the server can deal with the situation =E2=80=9Csoon,=E2=80=
=9D but perhaps not immediately.
> Again, a workaround. Not a very practical one, too. Most high performance=
web servers utilize micro-threading, which is not something C++ is even aw=
are of.
For best performance, don=E2=80=99t use exceptions at all. There=E2=80=99s =
currently an intensive study effort on high-performance coroutines, which w=
ill likely bear fruit after C++17.
This =E2=80=9Cworkaround=E2=80=9D doesn=E2=80=99t rely on, but rather avoid=
s C++ exceptions, and it should be compatible with any threading system: pr=
eemptive, cooperative, or ad-hoc. It=E2=80=99s really only a recommendation=
to separate concerns and put major work items under the control of some ki=
nd of dispatcher.
> In particular, the code I have in mind when judging your suggested altern=
atives is ghost, Akamai's proxy server. It drives 25% of the Internet's web=
traffic, and I'm simply not seeing it doing so the way you describe it sho=
uld.
Perhaps you could provide a more precise reference, to source code perhaps?=
(Even to a different project.)
>> As for the immediate recourse, C++17 will include a feature to allow des=
tructors to decide whether or not to throw. When not throwing, you can reco=
rd exceptions into std::exception_ptr objects, perhaps in thread-local stor=
age. Inspect and re-throw those pointers as appropriate. Such technique sho=
uld be more expressive and intuitive than built-in chaining could ever be.
> Maybe, but see my reply to Brian Bi, and later to T.C., for why what C++1=
7 isn't good enough (IMHO).
I don=E2=80=99t think that the proper usage and intent of uncaught_exceptio=
ns has (edit: had) been conveyed. In particular, =E2=80=9Cif (std::uncaught=
_exceptions() > 0)=E2=80=9D makes me wince because it is exactly the same a=
s if (std::uncaught_exception()) which is being deprecated.
For what it=E2=80=99s worth, I=E2=80=99m not sure that uncaught_exceptions =
is a reliable solution even when used properly, so I simply mentioned that =
the problem will be solved in time for C++17.
--=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/.
--Apple-Mail=_352FF47D-CF7B-478C-8032-D59285B29CD3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9324, at 7:04 PM, Shachar Shemesh <<a href=3D"mailto:shachar@ling=
nu.com" class=3D"">shachar@lingnu.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><ul style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-col=
or: rgb(255, 255, 255);" class=3D""><li class=3D"">In any situation where, =
in C++, the program would terminate, in D the new exception is added to the=
"next" field of the exception currently last in the chain</li></ul></div><=
/blockquote><div>So the would-be offending exception doesn=E2=80=99t get th=
rown. This is effectively the same as having a thread-local list of excepti=
ons that couldn=E2=80=99t be processed, which is within the scope of my <fo=
nt face=3D"Courier" class=3D"">exception_ptr</font> suggestion.</div><block=
quote type=3D"cite" class=3D""><div class=3D""><ul style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; backgr=
ound-color: rgb(255, 255, 255);" class=3D""><li class=3D"">The catch can qu=
ery the next header to scan the list and decide whether they want to do som=
ething about the collateral exceptions or not.<br class=3D""></li></ul></di=
v></blockquote><div>And if it doesn=E2=80=99t, the exceptions never get han=
dled. Not a good policy to bake into the core language.</div><div><br class=
=3D""></div><blockquote type=3D"cite" class=3D""><blockquote cite=3D"mid:5A=
25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com" type=3D"cite" style=3D"font-f=
amily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; white-sp=
ace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0p=
x; background-color: rgb(255, 255, 255);" class=3D""><div class=3D"">1. Mal=
icious connections should be torn down ASAP, no need to do things gracefull=
y.</div></blockquote><span style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255=
, 255); float: none; display: inline !important;" class=3D"">Huh? This stat=
ement is so wrong on so many levels:</span><br style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background=
-color: rgb(255, 255, 255);" class=3D""><ul style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-co=
lor: rgb(255, 255, 255);" class=3D""><li class=3D"">ASAP is as soon as you =
can detect it is malicious. You cannot detect malicious body until you've p=
arsed the request, the headers, looked up the resource etc. In other words,=
"soon" is a very relative term in this case.</li><li class=3D"">No need to=
do things gracefully? Seriously? What about the thousands of other connect=
ions this server is handling? Shouldn't they get a chance to use the memory=
you've allocated for this connection?</li></ul></blockquote><div>I was onl=
y speaking in terms of sockets, once the problem is detected. You shouldn=
=E2=80=99t need to buffer any additional data to gracefully end a malicious=
user=E2=80=99s TCP connection, which is what you seemed to be referring to=
..</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">=
<div style=3D"margin-bottom: 0.2cm; margin-top: 0pt; font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-co=
lor: rgb(255, 255, 255);" class=3D"">May I remind you that exceptions are t=
he only case where C++ potentially does dynamic heap allocations without yo=
u explicitly asking for it?</div></div></blockquote><div>Exception objects =
are usually allocated within a reserved arena. Heap allocation doesn=E2=80=
=99t sound like a conforming implementation of exceptions, at least not for=
<font face=3D"Courier" class=3D"">bad_alloc</font>.</div><br class=3D""><b=
lockquote type=3D"cite" class=3D""><div class=3D""><blockquote cite=3D"mid:=
5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@gmail.com" type=3D"cite" style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px; background-color: rgb(255, 255, 255);" class=3D""><div class=3D""><div=
class=3D"">2. If logging can throw, and you do it directly from destructor=
s, then you=E2=80=99re making a conscious decision that failure of the logg=
ing system may terminate the program.</div></div></blockquote><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255); float: none; display: in=
line !important;" class=3D"">You're<span class=3D"Apple-converted-space">&n=
bsp;</span></span><a href=3D"https://en.wikipedia.org/wiki/Begging_the_ques=
tion" style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=3D"">b=
egging the question</a><span style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 2=
55, 255); float: none; display: inline !important;" class=3D"">. The only r=
eason you're equating the two is because that's how C++ does things. </span=
></div></blockquote><div><br class=3D""></div><div>When a destructor throws=
, not only does unwinding get a headache, but the object hasn=E2=80=99t bee=
n destroyed. A destructor that fails to free resources when the log facilit=
y is unavailable isn=E2=80=99t a very good one.</div><div><br class=3D""></=
div><div>Exception-free destructors are the foundation of RTTI. C++ has goo=
d reason for doing things the way it does.</div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><span style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background=
-color: rgb(255, 255, 255); float: none; display: inline !important;" class=
=3D"">But that is precisely what I'm urging to change. You could log, have =
log failures throw and do it from a destructor without risking program term=
ination if my proposal is accepted. In fact, you've just validated the nece=
ssity. Thank you :-)</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255,=
255, 255);" class=3D""></div></blockquote><div><br class=3D""></div><div>Y=
ou still haven=E2=80=99t described how any of these exceptions will actuall=
y get handled.</div><br class=3D""><blockquote type=3D"cite" class=3D""><di=
v class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-s=
tyle: normal; font-variant: normal; font-weight: normal; letter-spacing: no=
rmal; line-height: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); =
float: none; display: inline !important;" class=3D"">2a and 2b are just wor=
karounds to the problem C++ is dumping at my door. They might be a good ide=
a anyway (debatable), but my point is that C++ should not force me to use t=
hem.</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" cla=
ss=3D""></div></blockquote><div><br class=3D""></div><div>Please provide a =
self-consistent outline of some alternative, including the restrictions on =
the <font face=3D"Courier" class=3D"">malicious_connection</font> handler. =
Is it allowed to attempt allocation or logging if it runs while there are a=
lready outstanding <font face=3D"Courier" class=3D"">bad_alloc</font> or <f=
ont face=3D"Courier" class=3D"">ios::failure</font> exceptions? Under what =
conditions does it re-throw the nested exception?</div><br class=3D""><bloc=
kquote type=3D"cite" class=3D""><blockquote cite=3D"mid:5A25FAB4-3A5C-4D95-=
A5E5-3A3BE67EEEFD@gmail.com" type=3D"cite" style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-col=
or: rgb(255, 255, 255);" class=3D""><div class=3D""><div class=3D"">A more =
sensible way to handle low-level exceptions is to have a protocol for offlo=
ading the exception-unsafe behavior from the destructor into an asynchronou=
s process or coroutine. If a destructor is unfortunate enough to realize th=
at a webpage can=E2=80=99t be served, don=E2=80=99t force it to try to sync=
hronously serve an error page. Enqueue some minimal information so the rest=
of the server can deal with the situation =E2=80=9Csoon,=E2=80=9D but perh=
aps not immediately.</div></div></blockquote><span style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; backgr=
ound-color: rgb(255, 255, 255); float: none; display: inline !important;" c=
lass=3D"">Again, a workaround. Not a very practical one, too. Most high per=
formance web servers utilize micro-threading, which is not something C++ is=
even aware of.</span><br style=3D"font-family: Helvetica; font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,=
255);" class=3D""></blockquote><div><br class=3D""></div><div>For best per=
formance, don=E2=80=99t use exceptions at all. There=E2=80=99s currently an=
intensive study effort on high-performance coroutines, which will likely b=
ear fruit after C++17.</div><div><br class=3D""></div><div>This =E2=80=9Cwo=
rkaround=E2=80=9D doesn=E2=80=99t rely on, but rather avoids C++ exceptions=
, and it should be compatible with any threading system: preemptive, cooper=
ative, or ad-hoc. It=E2=80=99s really only a recommendation to separate con=
cerns and put major work items under the control of some kind of dispatcher=
..</div><br class=3D""><blockquote type=3D"cite" class=3D""><span style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px; background-color: rgb(255, 255, 255); float: none; display: inline =
!important;" class=3D"">In particular, the code I have in mind when judging=
your suggested alternatives is ghost, Akamai's proxy server. It drives 25%=
of the Internet's web traffic, and I'm simply not seeing it doing so the w=
ay you describe it should.</span><br style=3D"font-family: Helvetica; font-=
size: 12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rg=
b(255, 255, 255);" class=3D""></blockquote><div><br class=3D""></div><div>P=
erhaps you could provide a more precise reference, to source code perhaps? =
(Even to a different project.)</div><br class=3D""><blockquote type=3D"cite=
" class=3D""><blockquote cite=3D"mid:5A25FAB4-3A5C-4D95-A5E5-3A3BE67EEEFD@g=
mail.com" type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 2=
55);" class=3D""><div class=3D""><div class=3D""></div><div class=3D"">As f=
or the immediate recourse, C++17 will include a feature to allow destructor=
s to decide whether or not to throw. When not throwing, you can record exce=
ptions into <font class=3D"" face=3D"Courier">std::exception_ptr</font=
><span class=3D"Apple-converted-space"> </span>objects, perhaps in thr=
ead-local storage. Inspect and re-throw those pointers as appropriate. Such=
technique should be more expressive and intuitive than built-in chaining c=
ould ever be.</div></div></blockquote><span style=3D"font-family: Helvetica=
; font-size: 12px; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: auto; text-ali=
gn: start; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-co=
lor: rgb(255, 255, 255); float: none; display: inline !important;" class=3D=
"">Maybe, but see my reply to Brian Bi, and later to T.C., for why what C++=
17 isn't good enough (IMHO).</span><br style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; orphans: auto; text-align: s=
tart; text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: =
rgb(255, 255, 255);" class=3D""></blockquote></div><br class=3D""><div clas=
s=3D"">I don=E2=80=99t think that the proper usage and intent of <font face=
=3D"Courier" class=3D"">uncaught_exceptions</font> has (edit: had) been con=
veyed. In particular, =E2=80=9C<font face=3D"Courier" class=3D"">if (std::u=
ncaught_exceptions() > 0)</font>=E2=80=9D makes me wince because it is e=
xactly the same as <font face=3D"Courier" class=3D"">if (std::uncaught_exce=
ption())</font> which is being deprecated.</div><div class=3D""><br class=
=3D""></div><div class=3D"">For what it=E2=80=99s worth, I=E2=80=99m not su=
re that <font face=3D"Courier" class=3D"">uncaught_exceptions</font> is a r=
eliable solution even when used properly, so I simply mentioned that the pr=
oblem will be solved in time for C++17.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_352FF47D-CF7B-478C-8032-D59285B29CD3--
.
Author: Shachar Shemesh <shachar@lingnu.com>
Date: Mon, 27 Apr 2015 20:51:27 +0300
Raw View
This is a multi-part message in MIME format.
--------------000303050806030206020907
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello David,
Sorry about the late response:
On 25/04/15 00:21, David Krauss wrote:
>
>> On 2015=E2=80=9304=E2=80=9324, at 7:04 PM, Shachar Shemesh <shachar@ling=
nu.com
>> <mailto:shachar@lingnu.com>> wrote:
>>
>> * In any situation where, in C++, the program would terminate, in D
>> the new exception is added to the "next" field of the exception
>> currently last in the chain
>>
> So the would-be offending exception doesn=E2=80=99t get thrown.
No. It would be more correct to say that would-be offending exception
doesn't propagate beyond the frame of the destructor that was called by
the unwind code.
> And if it doesn=E2=80=99t, the exceptions never get handled. Not a good p=
olicy
> to bake into the core language.
I beg to differ. If you know these exceptions might be important, do
ahead and scan them. If you know RAII has got you covered, ignore them.
True to the spirit of C++, the programmer has enough gun power to shoot
for the sky or shoot himself in the foot.
> I was only speaking in terms of sockets, once the problem is detected.
> You shouldn=E2=80=99t need to buffer any additional data to gracefully en=
d a
> malicious user=E2=80=99s TCP connection, which is what you seemed to be
> referring to.
No. It was not. I was referring to resources allocated by the header's
parser, chunked encoding parser, resource locator etc. These need to be
freed once we realize the connection is malicious, and they reside
higher up in the stack frame than where we are.
>
>> May I remind you that exceptions are the only case where C++
>> potentially does dynamic heap allocations without you explicitly
>> asking for it?
> Exception objects are usually allocated within a reserved arena. Heap
> allocation doesn=E2=80=99t sound like a conforming implementation of
> exceptions, at least not for bad_alloc.
Yes, they *usually* are. That's why I said "potentially". IIRC, they are
allocated from a pre-allocated space *if there is enough space there*.
bad_alloc can, pretty certainly, fit. If I throw an exception carrying a
2KB backtrace and extra info, maybe not. In that case, the compiler is
entitled to allocate the exception on the heap (if you want a really
nasty job interview question, feel free to ask where are exceptions
stored while in transit).
I will admit that what happens when you try to throw because there was
not enough memory, and now can't throw because of the same problem, did
not occur to me. Personally, I'm okay with calling terminate in such a
case. A case where we can't even begin the unwind is different, in my
eyes, then a case where an exception is thrown during the unwind.
>
> When a destructor throws, not only does unwinding get a headache, but
> the object hasn=E2=80=99t been destroyed. A destructor that fails to free
> resources when the log facility is unavailable isn=E2=80=99t a very good =
one.
I don't think this is as big a problem as you make it out to be. At the
end of the day, a destructor implementer should have enough
understanding of what the destructor is doing to implement something
sane. With that said, the problem is a real one, not only for C++. From
the Linux man page for close (closing a file descriptor):
> Not checking the return value of close() is a common but nevertheless
> serious programming error. It is quite possible that errors on a
> previous write(2) operation are first reported at the final close().=20
> Not checking the return value when closing the file may lead to
> silent loss of data. This can especially be observed with NFS and
> with disk quota. Note that the return value should only be used for
> diagnostics. In particular close() should not be retried after an
> EINTR since this may cause a reused descriptor from another thread
> to be closed.
In other words. Naughty you if you do not check the return value of
close, but we're not going to tell you of anything reasonable you can do
about it.
>
> Exception-free destructors are the foundation of RTTI. C++ has good
> reason for doing things the way it does.
You lost me. Can you point me to somewhere said reasoning is documented
so I can either give better arguments or concede my mistake?
>
>> But that is precisely what I'm urging to change. You could log, have
>> log failures throw and do it from a destructor without risking
>> program termination if my proposal is accepted. In fact, you've just
>> validated the necessity. Thank you :-)
>
> You still haven=E2=80=99t described how any of these exceptions will actu=
ally
> get handled.
If you are referring to what the programmer should see, then I believe I
gave a pretty good description. If there is anything there you do not
understand, please ask specific questions.
If you are referring to how the compiler should implement this, then the
idea is that, conceptually, each call to a destructor from the unwind
code would be surrounded by a try with catch( std::exception &ex ) {
current_tail->next =3D &ex;
current_tail =3D &ex;
}
this means that nested exceptions deriving from std::exception get
chained, while other exceptions call terminate, as per today.
>
>> 2a and 2b are just workarounds to the problem C++ is dumping at my
>> door. They might be a good idea anyway (debatable), but my point is
>> that C++ should not force me to use them.
>
> Please provide a self-consistent outline of some alternative,
> including the restrictions on the malicious_connection handler. Is it
> allowed to attempt allocation or logging if it runs while there are
> already outstanding bad_alloc or ios::failure exceptions?
yes.
> Under what conditions does it re-throw the nested exception?
I'm not sure what that means.
>
>> Again, a workaround. Not a very practical one, too. Most high
>> performance web servers utilize micro-threading, which is not
>> something C++ is even aware of.
>
> For best performance, don=E2=80=99t use exceptions at all. There=E2=80=99=
s currently
> an intensive study effort on high-performance coroutines, which will
> likely bear fruit after C++17.
>
> This =E2=80=9Cworkaround=E2=80=9D doesn=E2=80=99t rely on, but rather avo=
ids C++ exceptions,
> and it should be compatible with any threading system: preemptive,
> cooperative, or ad-hoc. It=E2=80=99s really only a recommendation to sepa=
rate
> concerns and put major work items under the control of some kind of
> dispatcher.
I think this is sidestepping the discussion. If we are going to cancel
exception support, then I agree this discussion is moot. Since I believe
that won't happen, then I feel discussing this within the context of
exception handling is the right thing to do.
> Perhaps you could provide a more precise reference, to source code
> perhaps? (Even to a different project.)
Sorry. Nothing off the top of my head. I'll try to have a look around later=
..
>
> For what it=E2=80=99s worth, I=E2=80=99m not sure that uncaught_exception=
s is a
> reliable solution even when used properly, so I simply mentioned that
> the problem will be solved in time for C++17.
And I'm trying to contribute my share as to how such proper solution
should look.
Thanks for listening,
Shachar
--=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/.
--------------000303050806030206020907
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html style=3D"direction: ltr;">
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
<style type=3D"text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt=
; } </style>
</head>
<body style=3D"direction: ltr;" bidimailui-charset-is-forced=3D"true"
bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Hello David,<br>
<br>
Sorry about the late response:<br>
<br>
On 25/04/15 00:21, David Krauss wrote:<br>
</div>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<br class=3D"">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">On 2015=E2=80=9304=E2=80=9324, at 7:04 PM, Shacha=
r Shemesh <<a
moz-do-not-send=3D"true" href=3D"mailto:shachar@lingnu.com"
class=3D"">shachar@lingnu.com</a>> wrote:</div>
<br class=3D"Apple-interchange-newline">
<div class=3D"">
<ul style=3D"font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);" class=3D"">
<li class=3D"">In any situation where, in C++, the program
would terminate, in D the new exception is added to the
"next" field of the exception currently last in the
chain</li>
</ul>
</div>
</blockquote>
<div>So the would-be offending exception doesn=E2=80=99t get thrown=
..</div>
</div>
</blockquote>
No. It would be more correct to say that would-be offending
exception doesn't propagate beyond the frame of the destructor that
was called by the unwind code.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div>And if it doesn=E2=80=99t, the exceptions never get handled. Not=
a
good policy to bake into the core language.</div>
</blockquote>
I beg to differ. If you know these exceptions might be important, do
ahead and scan them. If you know RAII has got you covered, ignore
them. True to the spirit of C++, the programmer has enough gun power
to shoot for the sky or shoot himself in the foot.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div>
<div>I was only speaking in terms of sockets, once the problem
is detected. You shouldn=E2=80=99t need to buffer any additional =
data
to gracefully end a malicious user=E2=80=99s TCP connection, whic=
h is
what you seemed to be referring to.</div>
</div>
</blockquote>
No. It was not. I was referring to resources allocated by the
header's parser, chunked encoding parser, resource locator etc.
These need to be freed once we realize the connection is malicious,
and they reside higher up in the stack frame than where we are.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D"">
<div style=3D"margin-bottom: 0.2cm; margin-top: 0pt;
font-family: Helvetica; font-size: 12px; font-style:
normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans:
auto; text-align: start; text-indent: 0px; text-transform:
none; white-space: normal; widows: auto; word-spacing:
0px; -webkit-text-stroke-width: 0px; background-color:
rgb(255, 255, 255);" class=3D"">May I remind you that
exceptions are the only case where C++ potentially does
dynamic heap allocations without you explicitly asking for
it?</div>
</div>
</blockquote>
<div>Exception objects are usually allocated within a reserved
arena. Heap allocation doesn=E2=80=99t sound like a conforming
implementation of exceptions, at least not for <font class=3D""
face=3D"Courier">bad_alloc</font>.</div>
</div>
</blockquote>
Yes, they <b>usually</b> are. That's why I said "potentially".
IIRC, they are allocated from a pre-allocated space <b>if there is
enough space there</b>. bad_alloc can, pretty certainly, fit. If I
throw an exception carrying a 2KB backtrace and extra info, maybe
not. In that case, the compiler is entitled to allocate the
exception on the heap (if you want a really nasty job interview
question, feel free to ask where are exceptions stored while in
transit).<br>
<br>
I will admit that what happens when you try to throw because there
was not enough memory, and now can't throw because of the same
problem, did not occur to me. Personally, I'm okay with calling
terminate in such a case. A case where we can't even begin the
unwind is different, in my eyes, then a case where an exception is
thrown during the unwind.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div><br>
<div>When a destructor throws, not only does unwinding get a
headache, but the object hasn=E2=80=99t been destroyed. A destruc=
tor
that fails to free resources when the log facility is
unavailable isn=E2=80=99t a very good one.</div>
</div>
</blockquote>
I don't think this is as big a problem as you make it out to be. At
the end of the day, a destructor implementer should have enough
understanding of what the destructor is doing to implement something
sane. With that said, the problem is a real one, not only for C++.
From the Linux man page for close (closing a file descriptor):<br>
<blockquote type=3D"cite">Not=C2=A0 checking the return value of close(=
) is
a common but nevertheless serious programming error.=C2=A0 It is quit=
e
possible that errors on a previous write(2) operation are first
reported at the final close().=C2=A0 Not checking the return value wh=
en
closing the file=C2=A0 may=C2=A0 lead to silent loss of data.=C2=A0 T=
his can
especially be observed with NFS and with disk quota.=C2=A0 Note that
the return value should only be used for diagnostics.=C2=A0 In
particular close() should not be retried after an EINTR since this
may cause a=C2=A0 reused=C2=A0 descriptor=C2=A0 from=C2=A0 another th=
read to be
closed.</blockquote>
In other words. Naughty you if you do not check the return value of
close, but we're not going to tell you of anything reasonable you
can do about it.<br>
<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div>
<div><br class=3D"">
</div>
<div>Exception-free destructors are the foundation of RTTI. C++
has good reason for doing things the way it does.</div>
</div>
</blockquote>
You lost me. Can you point me to somewhere said reasoning is
documented so I can either give better arguments or concede my
mistake?<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D""><span style=3D"font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); float: none;
display: inline !important;" class=3D"">But that is
precisely what I'm urging to change. You could log, have
log failures throw and do it from a destructor without
risking program termination if my proposal is accepted. In
fact, you've just validated the necessity. Thank you :-)</spa=
n><br
style=3D"font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);" class=3D"">
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>You still haven=E2=80=99t described how any of these exception=
s
will actually get handled.</div>
</div>
</blockquote>
If you are referring to what the programmer should see, then I
believe I gave a pretty good description. If there is anything there
you do not understand, please ask specific questions.<br>
<br>
If you are referring to how the compiler should implement this, then
the idea is that, conceptually, each call to a destructor from the
unwind code would be surrounded by a try with catch( std::exception
&ex ) {<br>
=C2=A0=C2=A0=C2=A0 current_tail->next =3D &ex;<br>
=C2=A0=C2=A0=C2=A0 current_tail =3D &ex;<br>
}<br>
<br>
this means that nested exceptions deriving from std::exception get
chained, while other exceptions call terminate, as per today.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D""><span style=3D"font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); float: none;
display: inline !important;" class=3D"">2a and 2b are just
workarounds to the problem C++ is dumping at my door. They
might be a good idea anyway (debatable), but my point is
that C++ should not force me to use them.</span><br
style=3D"font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255);" class=3D"">
</div>
</blockquote>
<div><br class=3D"">
</div>
<div>Please provide a self-consistent outline of some
alternative, including the restrictions on the <font class=3D""
face=3D"Courier">malicious_connection</font> handler. Is it
allowed to attempt allocation or logging if it runs while
there are already outstanding <font class=3D"" face=3D"Courier">b=
ad_alloc</font>
or <font class=3D"" face=3D"Courier">ios::failure</font>
exceptions?</div>
</div>
</blockquote>
yes.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div>
<div> Under what conditions does it re-throw the nested
exception?</div>
</div>
</blockquote>
I'm not sure what that means.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D""><span style=3D"font-family:
Helvetica; font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255,
255, 255); float: none; display: inline !important;"
class=3D"">Again, a workaround. Not a very practical one, too.
Most high performance web servers utilize micro-threading,
which is not something C++ is even aware of.</span><br
style=3D"font-family: Helvetica; font-size: 12px; font-style:
normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255,
255, 255);" class=3D"">
</blockquote>
<div><br class=3D"">
</div>
<div>For best performance, don=E2=80=99t use exceptions at all. The=
re=E2=80=99s
currently an intensive study effort on high-performance
coroutines, which will likely bear fruit after C++17.</div>
<div><br class=3D"">
</div>
<div>This =E2=80=9Cworkaround=E2=80=9D doesn=E2=80=99t rely on, but=
rather avoids C++
exceptions, and it should be compatible with any threading
system: preemptive, cooperative, or ad-hoc. It=E2=80=99s really o=
nly a
recommendation to separate concerns and put major work items
under the control of some kind of dispatcher.</div>
</div>
</blockquote>
I think this is sidestepping the discussion. If we are going to
cancel exception support, then I agree this discussion is moot.
Since I believe that won't happen, then I feel discussing this
within the context of exception handling is the right thing to do.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite">
<div>Perhaps you could provide a more precise reference, to source
code perhaps? (Even to a different project.)</div>
</blockquote>
Sorry. Nothing off the top of my head. I'll try to have a look
around later.<br>
<blockquote
cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com"
type=3D"cite"><br>
<div class=3D"">For what it=E2=80=99s worth, I=E2=80=99m not sure tha=
t <font
class=3D"" face=3D"Courier">uncaught_exceptions</font> is a
reliable solution even when used properly, so I simply mentioned
that the problem will be solved in time for C++17.</div>
</blockquote>
And I'm trying to contribute my share as to how such proper solution
should look.<br>
<br>
Thanks for listening,<br>
Shachar<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------000303050806030206020907--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 28 Apr 2015 17:55:30 +0800
Raw View
--Apple-Mail=_1AB5CF92-B188-48BB-83C5-22F871BBC5FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9328, at 1:51 AM, Shachar Shemesh <shachar@lingn=
u.com> wrote:
>=20
> On 25/04/15 00:21, David Krauss wrote:
>>=20
>> So the would-be offending exception doesn=E2=80=99t get thrown.
> No. It would be more correct to say that would-be offending exception doe=
sn't propagate beyond the frame of the destructor that was called by the un=
wind code.
Fair enough. It theoretically gets thrown, but stashed in an exception_ptr =
without being caught when the two unwind operations collide. But there=E2=
=80=99s almost no observable difference.
The implementation would be free to elide the throw when the proposal is in=
effect, and to immediately stash the object. An implementation is free to =
identify the target handler before starting to unwind.
C++17 will introduce a concept of checking whether the current unwinding co=
ntext was directly initiated by a previously recorded context (currently dr=
afted as std::uncaught_exceptions). Destructors in the inner unwind would n=
eed to observe the presence of the inner exception, regardless of whether i=
t=E2=80=99s caught. This would create a way for the program to observe its =
disappearance, complicating the above optimization.
> I beg to differ. If you know these exceptions might be important, do ahea=
d and scan them. If you know RAII has got you covered, ignore them.
The program can=E2=80=99t scan for every =E2=80=9Cimportant=E2=80=9D except=
ion in every other handler, especially in third-party libraries. Also as I =
mentioned, it=E2=80=99s hard to handle an inner exception if the outer exce=
ption already unwound the stack beyond its natural handler.
> No. It was not. I was referring to resources allocated by the header's pa=
rser, chunked encoding parser, resource locator etc. These need to be freed=
once we realize the connection is malicious, and they reside higher up in =
the stack frame than where we are.
That should be taken care of by RAII. Freeing those resources shouldn=E2=80=
=99t require first allocating something else, and resources spent on malici=
ous connections should be minimized, hence the suggestion that the destruct=
or close the connection =E2=80=9CASAP,=E2=80=9D or abandon it, as opposed t=
o following the protocol.
> IIRC, they are allocated from a pre-allocated space if there is enough sp=
ace there. bad_alloc can, pretty certainly, fit. If I throw an exception ca=
rrying a 2KB backtrace and extra info, maybe not.
The reserved space is only used for the exception object itself. Such a bac=
ktrace should be stored on the heap, only if new(std::nothrow) provides the=
storage.
> In that case, the compiler is entitled to allocate the exception on the h=
eap (if you want a really nasty job interview question, feel free to ask wh=
ere are exceptions stored while in transit).
That=E2=80=99s easy =E2=80=94 in the reserved area. =E2=80=9CIn transit=E2=
=80=9D includes the time from the initial throw until its final handler exi=
ts (without a rethrow).
The tricky question is where the result of std::current_exception resides, =
which may be the heap. If you call this function with a full heap, it can s=
ave a bad_alloc instead of whatever you expect.
> In other words. Naughty you if you do not check the return value of close=
, but we're not going to tell you of anything reasonable you can do about i=
t.
http://stackoverflow.com/q/22603025/153285 <http://stackoverflow.com/q/2260=
3025/153285>
>> Exception-free destructors are the foundation of RTTI. C++ has good reas=
on for doing things the way it does.
> You lost me. Can you point me to somewhere said reasoning is documented s=
o I can either give better arguments or concede my mistake?
Sorry, I said RTTI when I meant RAII.
If a destructor throws, some part of it wasn=E2=80=99t executed, therefore =
some resources weren=E2=80=99t freed or some protocol wasn=E2=80=99t follow=
ed. RAII is an all-or-nothing proposition.
struct foo {
controller *master;
char *buffer =3D new char[100];
foo::~foo() noexcept(false) {
std::clog << "ending foo\n"; // std::clog.exceptions() are enabled
master->release( this ); // potential dangling pointer in another o=
bject
delete[] buffer; // potential memory leak
}
};
You can work around using scope guards (emulating =E2=80=9Cfinally=E2=80=9D=
), or by doing risky and optional steps last, but destructor failure is usu=
ally considered irrecoverable. That=E2=80=99s why, since C++11, you have to=
explicitly say noexcept(false) to even get the possibility =E2=80=94 other=
wise it=E2=80=99s immediate termination.
>> You still haven=E2=80=99t described how any of these exceptions will act=
ually get handled.
> If you are referring to what the programmer should see, then I believe I =
gave a pretty good description. If there is anything there you do not under=
stand, please ask specific questions.
I=E2=80=99m asking how in general to guarantee that the chained exceptions =
will be unchained and handled.
>> Please provide a self-consistent outline of some alternative, including =
the restrictions on the malicious_connection handler. Is it allowed to atte=
mpt allocation or logging if it runs while there are already outstanding ba=
d_alloc or ios::failureexceptions?
> yes.
If an exception handler exits by a new exception, the original exception is=
lost. So if you catch an exception with a chained bad_alloc but get an ios=
::failure before getting a chance to peek at the chain, the bad_alloc will =
be forgotten. You have the option of re-throwing the bad_alloc even if unwi=
nding, but that will cause it to be chained to the ios::failure, which does=
n=E2=80=99t make much sense because there=E2=80=99s no particular relation =
between those two exceptions.
And the exceptions could just as easily be chained in the other order. How =
can the handlers be arranged to support that?
Wouldn=E2=80=99t you be better off setting global flags indicating failure =
of various systems, and polling them whenever a chain would be processed?
>>> Again, a workaround. Not a very practical one, too. Most high performan=
ce web servers utilize micro-threading, which is not something C++ is even =
aware of.
>>=20
>> For best performance, don=E2=80=99t use exceptions at all. There=E2=80=
=99s currently an intensive study effort on high-performance coroutines, wh=
ich will likely bear fruit after C++17.
>>=20
>> This =E2=80=9Cworkaround=E2=80=9D doesn=E2=80=99t rely on, but rather av=
oids C++ exceptions, and it should be compatible with any threading system:=
preemptive, cooperative, or ad-hoc. It=E2=80=99s really only a recommendat=
ion to separate concerns and put major work items under the control of some=
kind of dispatcher.
> I think this is sidestepping the discussion. If we are going to cancel ex=
ception support, then I agree this discussion is moot. Since I believe that=
won't happen, then I feel discussing this within the context of exception =
handling is the right thing to do.
You brought high-performance servers into the discussion. Which one uses C+=
+ exceptions for things like malicious connections?
It would be nice to integrate traditional exceptions with modern server arc=
hitectures. As long as throw is slow, though, there=E2=80=99s a motivation =
to allow it to be avoided.
In any case, a solution to the problem at hand without throwing anything is=
just as good, and doesn=E2=80=99t detract from throw.
>> For what it=E2=80=99s worth, I=E2=80=99m not sure that uncaught_exceptio=
ns is a reliable solution even when used properly, so I simply mentioned th=
at the problem will be solved in time for C++17.
> And I'm trying to contribute my share as to how such proper solution shou=
ld look.
I don=E2=80=99t see the connection between throwing a new exception during =
unwinding, and getting information about when the current unwinding started=
..
Any contributions on that topic would be appreciated, though.
--=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/.
--Apple-Mail=_1AB5CF92-B188-48BB-83C5-22F871BBC5FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9328, at 1:51 AM, Shachar Shemesh <<a href=3D"mailto:shachar@ling=
nu.com" class=3D"">shachar@lingnu.com</a>> wrote:</div></blockquote><blo=
ckquote type=3D"cite" class=3D""><br class=3D""></blockquote><blockquote ty=
pe=3D"cite" class=3D""><div class=3D""><div class=3D"moz-cite-prefix" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255);">On 25/04/15 00:21, Davi=
d Krauss wrote:<br class=3D""></div><blockquote cite=3D"mid:BEFE6F56-4A59-4=
161-BEAC-F0B63DF2F834@gmail.com" type=3D"cite" style=3D"font-family: Helvet=
ica; font-size: 12px; font-style: normal; font-variant: normal; font-weight=
: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background=
-color: rgb(255, 255, 255);" class=3D""><br class=3D""><div class=3D""><div=
class=3D"">So the would-be offending exception doesn=E2=80=99t get thrown.=
</div></div></blockquote><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255,=
255, 255); float: none; display: inline !important;" class=3D"">No. It wou=
ld be more correct to say that would-be offending exception doesn't propaga=
te beyond the frame of the destructor that was called by the unwind code.</=
span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: norm=
al; font-variant: normal; font-weight: normal; letter-spacing: normal; line=
-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-t=
ransform: none; white-space: normal; widows: auto; word-spacing: 0px; -webk=
it-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=3D"=
"></div></blockquote><div><br class=3D""></div><div>Fair enough. It theoret=
ically gets thrown, but stashed in an <font face=3D"Courier" class=3D"">exc=
eption_ptr</font> without being caught when the two unwind operations =
collide. But there=E2=80=99s almost no observable difference.</div><div><br=
class=3D""></div><div>The implementation would be free to elide the throw =
when the proposal is in effect, and to immediately stash the object. An imp=
lementation is free to identify the target handler before starting to unwin=
d.</div><div><br class=3D""></div><div>C++17 will introduce a concept of ch=
ecking whether the current unwinding context was directly initiated by a pr=
eviously recorded context (currently drafted as <font face=3D"Courier" clas=
s=3D"">std::uncaught_exceptions</font>). Destructors in the inner unwind wo=
uld need to observe the presence of the inner exception, regardless of whet=
her it=E2=80=99s caught. This would create a way for the program to observe=
its disappearance, complicating the above optimization.</div><br class=3D"=
"><blockquote type=3D"cite" class=3D""><div class=3D""><span style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px; background-color: rgb(255, 255, 255); float: none; display: inline !imp=
ortant;" class=3D"">I beg to differ. If you know these exceptions might be =
important, do ahead and scan them. If you know RAII has got you covered, ig=
nore them. </span></div></blockquote><div><br class=3D""></div><div><div>Th=
e program can=E2=80=99t scan for every =E2=80=9Cimportant=E2=80=9D exceptio=
n in every other handler, especially in third-party libraries. Also as I me=
ntioned, it=E2=80=99s hard to handle an inner exception if the outer except=
ion already unwound the stack beyond its natural handler.</div></div><br cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255); float: none; display: in=
line !important;" class=3D"">No. It was not. I was referring to resources a=
llocated by the header's parser, chunked encoding parser, resource locator =
etc. These need to be freed once we realize the connection is malicious, an=
d they reside higher up in the stack frame than where we are.</span><br sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: auto; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stro=
ke-width: 0px; background-color: rgb(255, 255, 255);" class=3D""></div></bl=
ockquote><div><br class=3D""></div><div>That should be taken care of by RAI=
I. Freeing those resources shouldn=E2=80=99t require first allocating somet=
hing else, and resources spent on malicious connections should be minimized=
, hence the suggestion that the destructor close the connection =E2=80=9CAS=
AP,=E2=80=9D or abandon it, as opposed to following the protocol.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255); float: none; display: in=
line !important;" class=3D""> IIRC, they are allocated from a pre-allocated=
space<span class=3D"Apple-converted-space"> </span></span><b style=3D=
"font-family: Helvetica; font-size: 12px; font-style: normal; font-variant:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-=
color: rgb(255, 255, 255);" class=3D"">if there is enough space there</b><s=
pan style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; di=
splay: inline !important;" class=3D"">. bad_alloc can, pretty certainly, fi=
t. If I throw an exception carrying a 2KB backtrace and extra info, maybe n=
ot. </span></div></blockquote><div><br class=3D""></div><div>The reserved s=
pace is only used for the exception object itself. Such a backtrace should =
be stored on the heap, only if <font face=3D"Courier" class=3D"">new(std::n=
othrow)</font> provides the storage.</div><br class=3D""><blockquote t=
ype=3D"cite" class=3D""><div class=3D""><span style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-=
color: rgb(255, 255, 255); float: none; display: inline !important;" class=
=3D"">In that case, the compiler is entitled to allocate the exception on t=
he heap (if you want a really nasty job interview question, feel free to as=
k where are exceptions stored while in transit).</span><br style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
; background-color: rgb(255, 255, 255);" class=3D""></div></blockquote><div=
><br class=3D""></div><div>That=E2=80=99s easy =E2=80=94 in the reserved ar=
ea. =E2=80=9CIn transit=E2=80=9D includes the time from the initial <font f=
ace=3D"Courier" class=3D"">throw</font> until its final handler exits (with=
out a rethrow).</div><div><br class=3D""></div><div>The tricky question is =
where the result of <font face=3D"Courier" class=3D"">std::current_exceptio=
n</font> resides, which may be the heap. If you call this function with a f=
ull heap, it can save a <font face=3D"Courier" class=3D"">bad_alloc</font> =
instead of whatever you expect.</div><br class=3D""><blockquote type=3D"cit=
e" class=3D""><div class=3D""><span style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb=
(255, 255, 255); float: none; display: inline !important;" class=3D"">In ot=
her words. Naughty you if you do not check the return value of close, but w=
e're not going to tell you of anything reasonable you can do about it.</spa=
n><br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=3D""><=
/div></blockquote><div><br class=3D""></div><div><a href=3D"http://stackove=
rflow.com/q/22603025/153285" class=3D"">http://stackoverflow.com/q/22603025=
/153285</a></div><br class=3D""><blockquote type=3D"cite" class=3D""><div c=
lass=3D""><blockquote cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmai=
l.com" type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; font=
-style: normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; text-indent:=
0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255)=
;" class=3D""><div class=3D""><div class=3D"">Exception-free destructors ar=
e the foundation of RTTI. C++ has good reason for doing things the way it d=
oes.</div></div></blockquote><span style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(=
255, 255, 255); float: none; display: inline !important;" class=3D"">You lo=
st me. Can you point me to somewhere said reasoning is documented so I can =
either give better arguments or concede my mistake?</span><br style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px; background-color: rgb(255, 255, 255);" class=3D""></div></blockquote><=
div><br class=3D""></div><div>Sorry, I said RTTI when I meant RAII.</div><d=
iv><br class=3D""></div><div>If a destructor throws, some part of it wasn=
=E2=80=99t executed, therefore some resources weren=E2=80=99t freed or some=
protocol wasn=E2=80=99t followed. RAII is an all-or-nothing prop=
osition.</div><div><br class=3D""></div><div><font face=3D"Courier" class=
=3D"">struct foo {</font></div><div><font face=3D"Courier" class=3D""> =
; controller *master;</font></div><div><font face=3D"Courier" class=
=3D""> char *buffer =3D new char[100];</font></div><div><font =
face=3D"Courier" class=3D""> foo::~foo() noexcept(false) {</fo=
nt></div><div><font face=3D"Courier" class=3D""> =
std::clog << "ending foo\n"; // std::clog.exceptions() are enabled</=
font></div><div><font face=3D"Courier" class=3D""> &nbs=
p; master->release( this ); // potential dangling pointer in another obj=
ect</font></div><div><font face=3D"Courier" class=3D""> =
delete[] buffer; // potential memory leak</font></div><div><font fa=
ce=3D"Courier" class=3D""> }</font></div><div><font face=3D"Co=
urier" class=3D"">};</font></div></div><div><br class=3D""></div><div>You c=
an work around using scope guards (emulating =E2=80=9C<font face=3D"Courier=
" class=3D"">finally</font>=E2=80=9D), or by doing risky and optional steps=
last, but destructor failure is usually considered irrecoverable. That=E2=
=80=99s why, since C++11, you have to explicitly say <font face=3D"Courier"=
class=3D"">noexcept(false)</font> to even get the possibility =E2=80=94 ot=
herwise it=E2=80=99s immediate termination.</div><div><br class=3D""></div>=
<div><blockquote type=3D"cite" class=3D""><div class=3D""><blockquote cite=
=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com" type=3D"cite" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255);" class=3D""><div class=
=3D""><div class=3D"">You still haven=E2=80=99t described how any of these =
exceptions will actually get handled.</div></div></blockquote><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255); float: none; display: in=
line !important;" class=3D"">If you are referring to what the programmer sh=
ould see, then I believe I gave a pretty good description. If there is anyt=
hing there you do not understand, please ask specific questions.</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-=
variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:=
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px; background-color: rgb(255, 255, 255);" class=3D""></div><=
/blockquote><div><br class=3D""></div><div>I=E2=80=99m asking how in genera=
l to guarantee that the chained exceptions will be unchained and handled.</=
div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><bl=
ockquote cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com" type=
=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; font-style: nor=
mal; font-variant: normal; font-weight: normal; letter-spacing: normal; lin=
e-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=3D=
""><div class=3D""><div class=3D"">Please provide a self-consistent outline=
of some alternative, including the restrictions on the<span class=3D"Apple=
-converted-space"> </span><font class=3D"" face=3D"Courier">malicious_=
connection</font><span class=3D"Apple-converted-space"> </span>handler=
.. Is it allowed to attempt allocation or logging if it runs while there are=
already outstanding<span class=3D"Apple-converted-space"> </span><fon=
t class=3D"" face=3D"Courier">bad_alloc</font><span class=3D"Apple-converte=
d-space"> </span>or<span class=3D"Apple-converted-space"> </span>=
<font class=3D"" face=3D"Courier">ios::failure</font>exceptions?</div></div=
></blockquote><span style=3D"font-family: Helvetica; font-size: 12px; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);=
float: none; display: inline !important;" class=3D"">yes.</span><br style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255);" class=3D""></div></bloc=
kquote><div><br class=3D""></div><div>If an exception handler exits by a ne=
w exception, the original exception is lost. So if you catch an exception w=
ith a chained <font face=3D"Courier" class=3D"">bad_alloc</font> but get an=
<font face=3D"Courier" class=3D"">ios::failure</font> before getting =
a chance to peek at the chain, the <font face=3D"Courier" class=3D"">bad_al=
loc</font> will be forgotten. You have the option of re-throwing the <font =
face=3D"Courier" class=3D"">bad_alloc</font> even if unwinding, but that wi=
ll cause it to be chained to the <font face=3D"Courier" class=3D"">ios::fai=
lure</font>, which doesn=E2=80=99t make much sense because there=E2=80=99s =
no particular relation between those two exceptions.</div><div><br class=3D=
""></div><div>And the exceptions could just as easily be chained in the oth=
er order. How can the handlers be arranged to support that?</div><div><br c=
lass=3D""></div><div>Wouldn=E2=80=99t you be better off setting global flag=
s indicating failure of various systems, and polling them whenever a chain =
would be processed?</div><br class=3D""><blockquote type=3D"cite" class=3D"=
"><div class=3D""><blockquote cite=3D"mid:BEFE6F56-4A59-4161-BEAC-F0B63DF2F=
834@gmail.com" type=3D"cite" style=3D"font-family: Helvetica; font-size: 12=
px; font-style: normal; font-variant: normal; font-weight: normal; letter-s=
pacing: normal; line-height: normal; orphans: auto; text-align: start; text=
-indent: 0px; text-transform: none; white-space: normal; widows: auto; word=
-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 2=
55, 255);" class=3D""><div class=3D""><blockquote type=3D"cite" class=3D"">=
<span class=3D"" style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); fl=
oat: none; display: inline !important;">Again, a workaround. Not a very pra=
ctical one, too. Most high performance web servers utilize micro-threading,=
which is not something C++ is even aware of.</span><br class=3D"" style=3D=
"font-family: Helvetica; font-size: 12px; font-style: normal; font-variant:=
normal; font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; w=
hite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wi=
dth: 0px; background-color: rgb(255, 255, 255);"></blockquote><div class=3D=
""><br class=3D""></div><div class=3D"">For best performance, don=E2=80=99t=
use exceptions at all. There=E2=80=99s currently an intensive study effort=
on high-performance coroutines, which will likely bear fruit after C++17.<=
/div><div class=3D""><br class=3D""></div><div class=3D"">This =E2=80=9Cwor=
karound=E2=80=9D doesn=E2=80=99t rely on, but rather avoids C++ exceptions,=
and it should be compatible with any threading system: preemptive, coopera=
tive, or ad-hoc. It=E2=80=99s really only a recommendation to separate conc=
erns and put major work items under the control of some kind of dispatcher.=
</div></div></blockquote><span style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255,=
255, 255); float: none; display: inline !important;" class=3D"">I think th=
is is sidestepping the discussion. If we are going to cancel exception supp=
ort, then I agree this discussion is moot. Since I believe that won't happe=
n, then I feel discussing this within the context of exception handling is =
the right thing to do.</span><br style=3D"font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant: normal; font-weight: normal; lett=
er-spacing: normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(25=
5, 255, 255);" class=3D""></div></blockquote><div><br class=3D""></div><div=
>You brought high-performance servers into the discussion. Which one uses C=
++ exceptions for things like malicious connections?</div><div><br class=3D=
""></div><div>It would be nice to integrate traditional exceptions with mod=
ern server architectures. As long as <span style=3D"font-family: Couri=
er;" class=3D"">throw</span> is slow, though, there=E2=80=99s a motiva=
tion to allow it to be avoided.</div><div><br class=3D""></div><div>In=
any case, a solution to the problem at hand without throwing anything is j=
ust as good, and doesn=E2=80=99t detract from throw.</div><br class=3D""><b=
lockquote type=3D"cite" class=3D""><div class=3D""><blockquote cite=3D"mid:=
BEFE6F56-4A59-4161-BEAC-F0B63DF2F834@gmail.com" type=3D"cite" style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px; background-color: rgb(255, 255, 255);" class=3D""><div class=3D"">For =
what it=E2=80=99s worth, I=E2=80=99m not sure that<span class=3D"Apple-conv=
erted-space"> </span><font class=3D"" face=3D"Courier">uncaught_except=
ions</font><span class=3D"Apple-converted-space"> </span>is a reliable=
solution even when used properly, so I simply mentioned that the problem w=
ill be solved in time for C++17.</div></blockquote><span style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
background-color: rgb(255, 255, 255); float: none; display: inline !importa=
nt;" class=3D"">And I'm trying to contribute my share as to how such proper=
solution should look.</span><br style=3D"font-family: Helvetica; font-size=
: 12px; font-style: normal; font-variant: normal; font-weight: normal; lett=
er-spacing: normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(25=
5, 255, 255);" class=3D""></div></blockquote></div><br class=3D""><div clas=
s=3D"">I don=E2=80=99t see the connection between throwing a new exception =
during unwinding, and getting information about when the current unwinding =
started.</div><div class=3D""><br class=3D""></div><div class=3D"">Any cont=
ributions on that topic would be appreciated, though.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_1AB5CF92-B188-48BB-83C5-22F871BBC5FD--
.
Author: Martin Ba <0xcdcdcdcd@gmx.at>
Date: Sat, 2 May 2015 11:54:01 -0700 (PDT)
Raw View
------=_Part_1856_523445880.1430592841470
Content-Type: multipart/alternative;
boundary="----=_Part_1857_102689524.1430592841470"
------=_Part_1857_102689524.1430592841470
Content-Type: text/plain; charset=UTF-8
On Wednesday, April 22, 2015 at 8:09:59 PM UTC+2, Shachar Shemesh wrote:
>
> Hi all,
>
> This, I think, is the most sore point in C++ today. Exception nesting.
>
> Current standard mandates that an exception thrown during stack unwind for
> another exception causes immediate program termination. This has led to
> many suggestions that destructors never throw. I find that suggestion both
> problematic and too onerous.
>
> It is problematic because in 99% of the cases, it is quite alright for
> destructors to throw. ... ...
>
May I humbly point to this piece: http://stackoverflow.com/a/4098662/321013
I'd say that 90% of destructors are totally fine because they just contain
cleanup / release code that never throws anyway.
Those destructors with commit/flush (or rollback) semantics that contain
code that can *legitimately* throw can:
* today: use std::uncaught_exception() to determine whether they are
allowed to throw and get some amount of false negatives
* in C++17: use std::uncaught_exceptionS() to accurately determine whether
they are allowed to throw, and if not, just (possibly log and) swallow it,
just like one of your proposed points.
For d'tors where throwing is legitimate (files, DB connections, ...) I do
not think it is too much to ask to do the explicit check dance in their
c'tor and d'tor.
I would love to hear a well thought out proposal that tries something like
D apparently does today by using / extending the machinery we already have
for http://en.cppreference.com/w/cpp/error/nested_exception
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_1857_102689524.1430592841470
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, April 22, 2015 at 8:09:59 PM UTC+2, Shachar =
Shemesh wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
=20
<div style=3D"direction:ltr" bgcolor=3D"#FFFFFF" text=3D"#000000">
Hi all,<br>
<br>
This, I think, is the most sore point in C++ today. Exception
nesting.<br>
<br>
Current standard mandates that an exception thrown during stack
unwind for another exception causes immediate program termination.
This has led to many suggestions that destructors never throw. I
find that suggestion both problematic and too onerous.<br>
<br>
It is problematic because in 99% of the cases, it is quite alright
for destructors to throw. ... ...<br></div></blockquote><div><br>May I =
humbly point to this piece: http://stackoverflow.com/a/4098662/321013<br><b=
r>I'd say that 90% of destructors are totally fine because they just contai=
n cleanup / release code that never throws anyway.<br><br>Those destructors=
with commit/flush (or rollback) semantics that contain code that can *legi=
timately* throw can:<br><br>* today: use std::uncaught_exception() to deter=
mine whether they are allowed to throw and get some amount of false negativ=
es<br>* in C++17: use std::uncaught_exceptionS() to accurately determine wh=
ether they are allowed to throw, and if not, just (possibly log and) swallo=
w it, just like one of your proposed points.<br><br>For d'tors where throwi=
ng is legitimate (files, DB connections, ...) I do not think it is too much=
to ask to do the explicit check dance in their c'tor and d'tor.<br><br>I w=
ould love to hear a well thought out proposal that tries something like D a=
pparently does today by using / extending the machinery we already have for=
http://en.cppreference.com/w/cpp/error/nested_exception<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" 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_1857_102689524.1430592841470--
------=_Part_1856_523445880.1430592841470--
.