On 18 Mar, 11:20, "Leigh Johnston"<le...@i42.co.uk> wrote:
"Yannick Tremblay"<ytrem...@nyx.nyx.net> 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