Is the exception specification being modified in the upcoming c++0x
standard?

I am very concerned especially of the double exception specification
behaviour. The current standard mandates that the program is terminated
on double exception. Well imho this is very wrong: silently dropping the
second exception (and maybe putting a string to stderr) would be a much
better behaviour. (E.g. Python does this)

The problem is that with such a specification it's not possible to make
any guarantee on the reliability of the software. How can anyone write
mission-critical apps using C++ if any double exception in a tiny bit of
code is going to terminate the full program?

Even if one wants to make a somewhat reliable web application server
this is a big problem: a programming error in one small piece is going
to bring the whole server down.

I understand that silently dropping an exception means most likely some
sort of memory leak... ok that's sad, in the long run one is going to
have problems, but it's anyway better than immediately terminating the
application.

At least the standard should leave the thing "implementation dependent"
so that compilers could leave decision to the user with compile options

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 12, 11:45 am, geronimo <geronim...@nowhere.com> wrote:
> I am very concerned especially of the double exception specification
> behaviour. The current standard mandates that the program is terminated
> on double exception. Well imho this is very wrong: silently dropping the
> second exception (and maybe putting a string to stderr) would be a much
> better behaviour. (E.g. Python does this)
>
> The problem is that with such a specification it's not possible to make
> any guarantee on the reliability of the software. How can anyone write
> mission-critical apps using C++ if any double exception in a tiny bit of
> code is going to terminate the full program?

Very easily: you don't write code that can cause "double exceptions",
by never throwing exceptions in destructors. The standard library
guarantees that for all its classes, and you should do the same for
yours.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Pavel Minaev" <int19h@gmail.com> wrote in message
news:f7df4188-6d48-416e-80ed-236b7a91e070@v1g2000prd.googlegroups.com...
>
> On May 12, 11:45 am, geronimo <geronim...@nowhere.com> wrote:
>>
>> I am very concerned especially of the double exception specification
>> behaviour. The current standard mandates that the program is terminated
>> on double exception. Well imho this is very wrong: silently dropping the
>> second exception (and maybe putting a string to stderr) would be a much
>> better behaviour. (E.g. Python does this)
>>
>> The problem is that with such a specification it's not possible to make
>> any guarantee on the reliability of the software. How can anyone write
>> mission-critical apps using C++ if any double exception in a tiny bit of
>> code is going to terminate the full program?
>
> Very easily: you don't write code that can cause "double exceptions",
> by never throwing exceptions in destructors. The standard library
> guarantees that for all its classes, and you should do the same for
> yours.

Actually, you can throw exceptions all you want in destructors as long
as you catch them in the destructor too.

There is one other type of double exception that may be a problem, and
that is the copy constructor of the exception object failing with a
constructor. Of course, in that case, it is impossible to propagate
the exception (unless the copy can be elided), so there is nothing the
program could sanely do except terminate.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]