Assertion vs Exception Handling

[Joshua Maurice]

Ugh, that's not good. Although the originally reported bug was thought
to be extremely rare (that's not an excuse not to fix it, of course,
I'm just saying), thanks to the info here it's clear it's not as rare
as originally thought.

Yeah thanks I found it on Microsoft Connect through a search.  The following
is a workaround to the problem: [...]
It is very lame of Microsoft that this bug was reported in early 2008 and is
still not fixed.

We just looked at this again, and we agree and apologize. We're now
planning to ship a fix for this in the first service pack to VC++
2010.

Thanks to James in particular for the additional use cases that
demonstrate the problem happens more often than originally thought,
and to Dilip Ranganathan for bringing this thread to our attention.

My company is currently using VS 2008. Any chance this fix will be
backported to this release or other releases? Or will we need to
upgrade to 2010? (I ask because we just went to 2008 like ~3 months
ago, and that was a nontrivial task.)

 

[JustBoo]

Posting by idiots is not irrelevant when you have to waste time replying
to said posts correcting stupid opinions such as "you must re-throw all
exceptions and have your program terminate". If you don't do this then
newbies are likely to learn bad practices.
/Leigh

Being so rude and unpopular you obviously never got the "memo." There
are no more newbies. They've all been chased away and are now writing
high-performance simulators using Python and the world's next-gen
"websites" using Ruby On Rails.

Also in the memo is the rule: The Q-Continuum Will Never, Ever Change.

 

[JustBoo]

I have come to the conclusion that this newsgroup is mostly a
pissing contest.
/Leigh

There are those of us that figured that out in 1995. You're way late
to the party, scarry.

"To conquer oneself is the best and noblest victory; to be vanquished
by one's own nature is the worst and most ignoble defeat." - Plato

 

[James Kanze]

"Yannick Tremblay"<[email protected]> wrote in message

[...]

The correct alternative (which I am sure James does) is to
write exception safe code that can cope with exceptions
and stack unrolling at any line in the function. Such
code gain a lot less value from SESE but still suffer by
the (slight) obfuscation.
Indeed and it is because of RAII and exceptions that there
is little difference between SESE and SEME in C++ except
one of coding style and the fact that SESE can sometimes
make a function easier to understand. You could argue that
SESE is a lie in C as well when you consider the existence
of setjmp/longjmp.

You could argue that SESE is a lie in any language, when you
consider the existance of machine crashes. SESE only
really concerns analysis of program correction and
understanding of the code. If you're functions are complex
enough that the alternative control flows aren't easily
analysable, they're probably too long, SESE or not. SESE
simplifies analysis, but it doesn't guarantee correctness.
(And exceptions do introduce additional issues. But a
function which exits via an exception generally doesn't have
to meet its full set of post-conditions.)

But it probably should clean up before leaving. Which leads
to exception safe code and relegates the SESE/SEME decision to
one of style.

For some definition of "clean up". Cleaning up is part of the
post-conditions. But the post-conditions when leaving a
function due to an exception are generally far weaker than when
leaving it normally: leave the function normally, and you can
expect objects to have a certain, explicit state; leave via an
exception, and all that is guaranteed is that the objects can be
destructed (for example).

The motivation for SESE is to facilitate proving that the code
works as intended. You leave via an exception when you know
that it can't work as intended. (For some appropriate
definition of "intended", of course.)

 

[Ian Collins]

[...]
The correct alternative (which I am sure James does) is to
write exception safe code that can cope with exceptions
and stack unrolling at any line in the function. Such
code gain a lot less value from SESE but still suffer by
the (slight) obfuscation.
Indeed and it is because of RAII and exceptions that there
is little difference between SESE and SEME in C++ except
one of coding style and the fact that SESE can sometimes
make a function easier to understand. You could argue that
SESE is a lie in C as well when you consider the existence
of setjmp/longjmp.
You could argue that SESE is a lie in any language, when you
consider the existance of machine crashes. SESE only
really concerns analysis of program correction and
understanding of the code. If you're functions are complex
enough that the alternative control flows aren't easily
analysable, they're probably too long, SESE or not. SESE
simplifies analysis, but it doesn't guarantee correctness.
(And exceptions do introduce additional issues. But a
function which exits via an exception generally doesn't have
to meet its full set of post-conditions.)

But it probably should clean up before leaving. Which leads
to exception safe code and relegates the SESE/SEME decision to
one of style.

For some definition of "clean up". Cleaning up is part of the
post-conditions. But the post-conditions when leaving a
function due to an exception are generally far weaker than when
leaving it normally: leave the function normally, and you can
expect objects to have a certain, explicit state; leave via an
exception, and all that is guaranteed is that the objects can be
destructed (for example).

The same can generally be said for an early return, but I get your point.

The motivation for SESE is to facilitate proving that the code
works as intended. You leave via an exception when you know
that it can't work as intended. (For some appropriate
definition of "intended", of course.)

I agree SESE can make code analysis easier, but Yannick's example in his
reply is a strong counter example. I also prefer an immediate return if
a precondition test fails.

 

[James Kanze]

On 03/19/10 07:21 AM, James Kanze wrote:
[...]

The motivation for SESE is to facilitate proving that the
code works as intended. You leave via an exception when you
know that it can't work as intended. (For some appropriate
definition of "intended", of course.)

I agree SESE can make code analysis easier, but Yannick's
example in his reply is a strong counter example. I also
prefer an immediate return if a precondition test fails.

Yes. It's a general rule, not an absolute. I violate it myself
in some cases[1]. In practice, I feel that keeping the function
simple and concise is more important. Not that one precludes
the other, but in my experience, if analysing the function isn't
trivial, it's more often because the function is too complicated
to begin with---SESE would make the analysis simpler, but
breaking the function down into smaller functions would make it
even simpler.

[1] In one case, I don't think it's even possible to follow it.
I have a function which consists of nothing but a switch, each
of which cases ends in a return. The return type doesn't have a
default constructor (and the switch covers all of the cases).