Error returns and repeated code, GOTOs, etc.

[Jean-Christophe]

I used 'struct bar',
for all of them, for sake of example.
It's very likely that in real world code
they are all different types,
with different functions to allocate them and unallocate them,
and so some code to iterate over them is likely to be
some more confusing than helpful.

I'd rather encapsulate functions pointers
( allocate, init, ... etc ... )
into the structure itself, to allow the
use of identical syntax all down the code.
It makes it more readable, and shorter.
And still, this is not C++, juste pure C.

 

[mike3]

mike3 <[email protected]> writes:

Yes.

Thanks for the explanation.

Give an example, and I'll comment. I can't see exactly what it is you
are saying. I presume it is not just the code that you originally
posted, since I commented on that.

Having, multiple early error cases does not always lead to conceptually
deep nesting. If you have:

if (C1) {
rc = E1;
goto error;
}
if (C2) {
rc = E2;
goto error;
}
if (C3) {
rc = E3;
goto error;
}
/* main error-free code */
error:
/* common clean-up code */
return rc;

you can turn it into:

if (C1)
rc = E1;
else if (C2)
rc = E2;
else if (C3)
rc = E3;
else {
/* main error-free code */
}
/* common clean-up code */
return rc;

That's deeply nested in the most literal sense, but no one would have
any trouble reasoning about the nesting, eleven if were 100 levels deep.

So you're suggesting to abuse the if() to create a list of executed
functions
that breaks off at an error, then, right? Is that a "dirty" trick?

 

[Ben Bacarisse]

Thanks for the explanation.



So you're suggesting to abuse the if() to create a list of executed
functions
that breaks off at an error, then, right? Is that a "dirty" trick?

I can't made head or tail of that. If you consider my use of if .. else
if ... to be an abuse, I doubt we have enough common ground debate this
point, but that seems like an unlikely position to hold and does not
explain the "list of executed functions" remark.

 

[Ben Bacarisse]

I like allocation functions that set the carry bit on failure.

I wish you and the carry bit all the best.

<snip>

 

[BartC]

"BartC" <[email protected]> ha scritto nel messaggio

so you know what structured programming mean?

Something like this I guess:

http://en.wikipedia.org/wiki/Structured_programming

so Djikstra know what structured programming mean?
"structured programming" has something in common to write
down in code the correct algo?

if someone speak not good for goto he/she make wrong...
he she don't know to what he she is talking about...

It's not just black and white. You wouldn't use 'goto' to replace the
if-else, while, do-while, switch and for statements, because the code would
be much more obscure. But I can't see the problem in using it where no
suitable control statement exists (although others would argue that it is
better then to turn the code upside-down so that it does fit into the
statements that are available).

(I couldn't find a copy of Dijkstra's letter; there's an annotated version
here, with his text in blue: http://david.tribble.com/text/goto.html)

it is good find a way to write easy one algo
and find a way for find easily errors in that too
but it need art

It needs that you are the one who wrote the original code, and that you are
reading the same code five minutes later.

 

[Willem]

tom st denis wrote:
)> Another method is to have all 'bignum' functions check for 'error' inputs
)> and generate 'error' outputs when they encounter them (or whenever they
)> ?encounter an error), and then you only have to check for an 'error'
)> result at the very end.
)>
)> Something like:

<snip>

)> The only weirdside to this is when a value is not used in the final result,
)> then that value will not be checked for errors.
)
) That only works if you capture the error codes in your bignum
) structure otherwise it's not thread safe.

I don't see any way to implement what I described other than storing
the error codes in the bignum structures.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Stefan Ram]

be much more obscure. But I can't see the problem in using it where no
suitable control statement exists (although others would argue that it is

One of the problems is code alteration: When you have a
large section of code including jump statements, it might be
difficult to extract a part of it into a method (jumps might
go into and out of this section, which will not work anymore
after extraction) or to do other forms of code alteration.

When each block has exactly one entrance at its beginning
and exactly one exit at its end, I call it a »structured
block«.

The code alteration of the first paragraph seems to be
easier with structured blocks. It also might be easier to
read and to argue about properties of that code segment or
to prove them; the mere wording »precondition«,
»postcondition«, and »invariant« of a block seem to imply
that it is a structured block.

 

[Jean-Christophe]

Dijkstra know what structured programming mean?

Edsgar Dijkstra is a quiche eater:
http://powerdown.free.fr/rp.html

 

[Ben Bacarisse]

Edsgar Dijkstra is a quiche eater:
http://powerdown.free.fr/rp.html

"Was", not "is". He died in 2002.

To get a flavour of what a real "quiche eater" is like, read his
development of a program to find the convex hull of a set of 3D points,
which is done in parallel with the development of a proof of the
algorithm's correctness.[1] In fact, read the whole book, if you have
time. It changed the way I think about programming.

[1] E. W. Dijkstra, "A Discipline of Programming", Prentice Hall, 1977,
Chapter 24, pp 168--191.

 

[Joe keane]

If you insist.

void func(int x)
{
std::unique_ptr<bar> a = new bar();
std::unique_ptr<bar> b = new bar();
std::unique_ptr<bar> c = new bar();

...
}

Does it return the correct error code if an error occurs in the
unallocate function?

 

[Martin Shobe]

Does it return the correct error code if an error occurs in the
unallocate function?

Return it? No. But it would throw the correct exception.

Martin Shobe

 

[Ike Naar]

Edsgar Dijkstra is a quiche eater:
http://powerdown.free.fr/rp.html

"Was", not "is". He died in 2002.

To get a flavour of what a real "quiche eater" is like, read his
development of a program to find the convex hull of a set of 3D points,
which is done in parallel with the development of a proof of the
algorithm's correctness.[1] In fact, read the whole book, if you have
time. It changed the way I think about programming.

[1] E. W. Dijkstra, "A Discipline of Programming", Prentice Hall, 1977,
Chapter 24, pp 168--191.

Another book, that describes the same ideas in a more accessible manner,
is David Gries' "The Science of Programming", Springer, 1981.
With a foreword by E.W. Dijkstra.

 

[Joe keane]

The code alteration of the first paragraph seems to be
easier with structured blocks. It also might be easier to
read and to argue about properties of that code segment or
to prove them; the mere wording »precondition«,
»postcondition«, and »invariant« of a block seem to imply
that it is a structured block.

What i see here is that the postcondition typically comprises two
conditions, one for normal exit, one for error exit, and they are
usually pretty dissimilar. So i'm not sure that insisting on one
postcondition really buys you any simplicity.

In terms of code, it's always nice to see the normal exit first, then
the error handling. Someone who just wants to get some idea how a
function works does not need to plow through the latter. Of course we
want to be sure that it's right, but it's often just distracting.

 

[Stefan Ram]

What i see here is that the postcondition typically comprises two
conditions

It is not mentioned on

http://en.wikipedia.org/wiki/Postcondition

and I am not aware of any source speaking of such /two/
postconditions.

 

[Joe keane]

It is not mentioned on

http://en.wikipedia.org/wiki/Postcondition

?

'a postcondition is a condition or predicate that must always be true
just after the execution of some section of code'

e.g.

int foo(int x)
{
int y;

if (x == 0)
{
y = 0;
}
else
{
y = 1;
}

return y;
}

A precondition of the first block is "x == 0".
A precondition of the second block is "x != 0".
A postcondition of the first block is "x == 0 && y == 0".
A postcondition of the second block is "x != 0 && y != 0".

A postcondition of the if/else construct is
"x == 0 && y == 0 || x != 0 && y != 0".

 

[Stefan Ram]

A precondition of the first block is "x == 0".

This is the /second/ compound statement. The /first/
compound statement starts at the first brace in your code.

A postcondition of the first block is "x == 0 && y == 0".

¯¯¯
. There is no source that says so (except your post).

 

[Joe keane]

and I am not aware of any source speaking of such /two/
postconditions.

http://en.wikipedia.org/wiki/Hoare_triple#Conditional_rule

any language with an if/else construct has two postconditions

{B && P} S {Q}, {!B && P} T {Q}
----
{P} if B then S else T endif {Q}

or mine

{B && P} S {Q}, {!B && P} T {R}

 

[Stefan Ram]

any language with an if/else construct has two postconditions

A language does not have postconditions,
a statement has a postcondition.

The webpage you mentioned does not support
your claims.

 

[Martin Shobe]

http://en.wikipedia.org/wiki/Hoare_triple#Conditional_rule

any language with an if/else construct has two postconditions

{B && P} S {Q}, {!B && P} T {Q}

Only one postcondition here (namely Q).

or mine

{B && P} S {Q}, {!B && P} T {R}
----
{P} if B then S else T endif {Q || R}

identical since "Q" -> "Q || R", "R" -> "Q || R", "Q || Q" -> "Q" are
tautologies

Again, only one post condition here (namely Q || R).

And before you try to say that Q is one postcondition and R is the
other, consider that, in general, neither Q nor R are postconditions by
themselves.

Martin Shobe


Martin Shobe

 

[Joe Pfeiffer]

This is the /second/ compound statement. The /first/
compound statement starts at the first brace in your code.

¯¯¯
. There is no source that says so (except your post).

I think he's talking about what he's seen in his experience, not a
definition -- that he's tended to see postconditions of the form
(a || b) where 'a' means "the postcondition you'd expect from a naive
statement of the algorithm" and 'b' means "some strange kludge that came
about as a result of an error in the course of executing the code".