Error returns and repeated code, GOTOs, etc.

[BartC]

בת×ריך ×™×•× ×©×‘×ª, 9 ביוני 2012 01:14:43 UTC+1, מ×ת Bart: .....

The central mistake is that the the consturctor takes an empty structure
to fill in, rather than returning a pointer to an allocated structure.
Then the destructor itself can return an error.
Change this, and you get

Init(a); if(x) goto f0;
Init(b); if(x) goto f0;
Init(c); if(x) goto f0;
Init(d); if(x) goto f0;

Set(b,3); if(x) goto f0;

Free(d);
Free(c);
Free(b);
Free(a);
return(p);

f0: Free(d);
Free(c);
Free(b);
Free(a);
return(q);

That's much mpre acceptable. The control flow is still doiminated by
gotos, but that's because all the calls can return errors, which go into a
single error handler.

Yes. And now the two blocks of Frees are almost identical, and they can be
combined into one. At that point you'll probably change the initialisation
to be something like:

if (Init(a) && Init(b) ... )
Set(b,3);
Free(d);
...

However there is the requirement to return one of several error codes,
either from the first failing Init(), from a failing Set(), or from a first
failing Free() (but in case of a failure here, all remaining objects must
still be freed).

It's this elevating the importance of an error return far above that of any
actual results, that is causing the difficulties. The design needs more work
to make it easier to manage allocation and returns, otherwise programming
anything non-trivial (or even trivial!) will be impossible.

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×‘×ª,9 ביוני 2012 16:12:51 UTC+1, מ×ת Bart:

However there is the requirement to return one of several error codes,
either from the first failing Init(), from a failing Set(), or from a first
failing Free() (but in case of a failure here, all remaining objects must
still be freed).

Usually two things can go wrong. Either there was a programming error, or the
computer ran out of memory.

If there's a programming error, fundamentally there's nothing good you can do.
If the computer ran out of memory, usually that indicates a programming error
(sensible integers can't exceed the memory capacity of a 4gigabyte machine).
The problem with C is that you have to handle and report the situation.

It's this elevating the importance of an error return far above that of any
actual results, that is causing the difficulties. The design needs more work
to make it easier to manage allocation and returns, otherwise programming
anything non-trivial (or even trivial!) will be impossible.

C doesn't distinguish between error processing and the normal control paths..
But you can keep such a distinction, by defing a label error_exit; Once
you've jumped to that able, the program is in error state. Generally you
need to pass up error returns through the call stack, until some function
knows whether it's better to suppress the error, inform the user, or terminate.

 

[Joe keane]

Init(a); if(x) goto f0;
Init(b); if(x) goto f1;
Init(c); if(x) goto f2;
Init(d); if(x) goto f3;

Set(b,3); if(x) goto f4;

Free(d); if(x) goto f3;
Free(c); if(x) goto f2;
Free(b); if(x) goto f1;
Free(a); if(x) goto f0;
return(p);

f4: Free(d);
f3: Free(c);
f2: Free(b);
f1: Free(a);
f0:
return(q);

Excellent! Thanks!

I think you just showed how to write good code.

 

[Guest]

"Malcolm McLean" <[email protected]> ha scritto nel messaggio
news:[email protected]...

<snip>

against my better judgement I'm goign to try a decode one of io_x's posts

Usually two things can go wrong. Either there was a programming error, or the
computer ran out of memory.

If there's a programming error, fundamentally there's nothing good you can do.

#but i know *there is some error* for correct it, and where the error is...
#i make errors, it is for this, each single bit for find-correct error is good
#is not a .exe space problem, not a time problem...
#but possibly all you not make errors, so not have the need to
#find-correct them...

are you trying to say something like this:-

"but even in the case of a programming error a good diagnostic
will tell you at least where the error occurred; and the more
information that can be provided the easier it is to track down
the root cause. Perhaps the rest of you don't make programming errors!"

if so I have some sympathy. The humble assert() should not be neglected.
Perhaps your unit tests need to be improved?

 

[Phil Carmody]

I wish you and the carry bit all the best.

What carry bit? I've searched high and low on my poor old Alpha,
and can't find one.

Phil
--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)

 

[Ben Bacarisse]

What carry bit? I've searched high and low on my poor old Alpha,
and can't find one.

Why are you asking me?

 

[Joe keane]

Init(a); if(x) goto f0;
Init(b); if(x) goto f0;
Init(c); if(x) goto f0;
Init(d); if(x) goto f0;

Set(b,3); if(x) goto f0;

Free(d);
Free(c);
Free(b);
Free(a);
return(p);

f0: Free(d);
Free(c);
Free(b);
Free(a);
return(q);

This code looks wrong.

If 'Init(a)' fails, then we go to 'Free(d)'?

I'm sure that you can make it work, somehow.

My point is that error handling is not that hard: if some 'allocate'
fails we go to the 'unallocate' of the previous one.

If you follow this rule, you should have correct code.

If you try to get 'clever' about it, that's when mistakes slip in.
Mistakes in error handling suck.

 

[BartC]

This code looks wrong.

If 'Init(a)' fails, then we go to 'Free(d)'?

I'm sure that you can make it work, somehow.

I think the idea was that an unconditional Free() is used, where it knows
(even without a formal Init()) whether a particular object needs freeing.
(For example, where an object is a pointer set to NULL.)

My point is that error handling is not that hard: if some 'allocate'
fails we go to the 'unallocate' of the previous one.

But the logic for that can become labyrinthic. (Eg. suppose each of the
previous Inits() were conditional, or initialised in an different order each
time?)

There are other approaches to just freeing everything on exit; perhaps each
Init() can add an object to a local list of objects that need freeing, then
only those need to be checked on a common exit. This is useful where there
are large numbers of objects of which only some might be active at any time,
or it fails early on.

If you try to get 'clever' about it, that's when mistakes slip in.
Mistakes in error handling suck.

Have a look at the OP's original code: the one with gotos, and the one
without. The latter especially is quite long-winded, and likely to be more
error-prone that something a lot shorter.

 

[Guest]

the error occurred and where; the problem is one presumible little
slow down...

"it may slow the program down a little"?

but if someone search for error search in memory allready
load or that has to be load for doing the calculation

sorry I haven't taken the advanced class in gibberish!

i not use assert()

no surprise!

 

[Joe keane]

Have a look at the OP's original code: the one with gotos, and the one
without. The latter especially is quite long-winded, and likely to be more
error-prone that something a lot shorter.

I think we're violently in agreement here: trying to make code
goto-free, because 'all gotos are evil', results in code that is more
bulky and more error-prone.

 

[Guest]

I think we're violently in agreement here: trying to make code
goto-free, because 'all gotos are evil', results in code that is more
bulky and more error-prone.

you may be in agreement but many posters on this thread are not.
(just when did "evil" become a fashionable word to use in programming? And why?)

 

[James Kuyper]

you may be in agreement but many posters on this thread are not.
(just when did "evil" become a fashionable word to use in programming? And why?)

According to groups.google.com, the first use of 'evil' in the comp.*
hierarchy was on 1986-11-09, just 13 days after the first message posted
to that hierarchy. I think it was already fashionable at that time, but
I don't know any easy way to determine when that happened.

 

[Guest]

On 06/13/2012 03:58 AM, (e-mail address removed) wrote:


According to groups.google.com, the first use of 'evil' in the comp.*
hierarchy was on 1986-11-09, just 13 days after the first message posted
to that hierarchy. I think it was already fashionable at that time, but
I don't know any easy way to determine when that happened.

ah so there is nothing new under the sun. I'd only recently encountered this usage (the C++ FAQ uses it a lot) so I assumed it was some "new fangled" thing. I'd use words like "ill-advised" or "indicitive of potential problems" but "evil" is shorter...

I have a similar teeth gritting reflex when I come across "code smell"

 

[gwowen]

you may be in agreement but many posters on this thread are not.
(just when did "evil" become a fashionable word to use in programming? And why?)

Looking at http://www.catb.org/jargon/oldversions/ it makes it into
the Jargon File some time about revision 2.1.5 (November 1990).

 

[Les Cargill]

you may be in agreement but many posters on this thread are not.
(just when did "evil" become a fashionable word to use in programming? And why?)

When people stopped thinking about it. Any use of the word "evil" is a
signal that the speaker has stopped thinking about it.

 

[James Kuyper]

When people stopped thinking about it. Any use of the word "evil" is a
signal that the speaker has stopped thinking about it.

You just used that word.

There's nothing wrong with stopping thinking about something, so long as
you've completed your thinking about it, and have moved on to thinking
about something else. I think perhaps you intended to say something like
"... has not given sufficient thought to it."
If so, I would disagree - I think it's perfectly possible to give
sufficient thought to something, and come to the conclusion that it can
be described as "evil". It's a normative judgement, and as such
inherently subjective, but no more or less so than "good".

 

[Willem]

James Kuyper wrote:
) On 06/13/2012 01:47 PM, Les Cargill wrote:
)> When people stopped thinking about it. Any use of the word "evil" is a
)> signal that the speaker has stopped thinking about it.
)
) You just used that word.
)
) There's nothing wrong with stopping thinking about something, so long as
) you've completed your thinking about it, and have moved on to thinking
) about something else. I think perhaps you intended to say something like
) "... has not given sufficient thought to it."
) If so, I would disagree - I think it's perfectly possible to give
) sufficient thought to something, and come to the conclusion that it can
) be described as "evil". It's a normative judgement, and as such
) inherently subjective, but no more or less so than "good".

To paraphrase:

" I think you meant to say something else, which I disagree
with, however I do agree with what you actually said. "

Debate club much?


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

 

[James Kuyper]

James Kuyper wrote:
) On 06/13/2012 01:47 PM, Les Cargill wrote:
)> When people stopped thinking about it. Any use of the word "evil" is a
)> signal that the speaker has stopped thinking about it.
)
) You just used that word.
)
) There's nothing wrong with stopping thinking about something, so long as
) you've completed your thinking about it, and have moved on to thinking
) about something else. I think perhaps you intended to say something like
) "... has not given sufficient thought to it."
) If so, I would disagree - I think it's perfectly possible to give
) sufficient thought to something, and come to the conclusion that it can
) be described as "evil". It's a normative judgement, and as such
) inherently subjective, but no more or less so than "good".

To paraphrase:

" I think you meant to say something else, which I disagree
with, however I do agree with what you actually said. "

If he meant what he actually said, there was little point in saying it,
at least in this context. If my guess about what he meant to say is
correct, there was a point in saying it, at least from the point of view
of someone who believes it to be true. I've heard similar sentiments
expressed before, often enough to justify considering the possibility
that it is indeed what he meant to say.

 

[Les Cargill]

You just used that word.

There's nothing wrong with stopping thinking about something, so long as
you've completed your thinking about it, and have moved on to thinking
about something else. I think perhaps you intended to say something like
"... has not given sufficient thought to it."

Probably. I meant more like "let's just round it up to evil". Either
that, or I wanted it to be one of those pithy Malcolm Gladwell style
aphorisms.

If so, I would disagree - I think it's perfectly possible to give
sufficient thought to something, and come to the conclusion that it can
be described as "evil". It's a normative judgement, and as such
inherently subjective, but no more or less so than "good".

Anything that is commonly described as evil usually has a more or less
reasonable explanation behind it. Simply declaring it beyond
understanding is, in my opinion, just not wanting to do your homework.

Granted, sometimes the homework is simply insurmountable. But it would
be, in my opinion, more honest to just say that.

If I had to just mark, say, the Dred Scott decision as simply
evil, I'd lose out on a lot of detail.

So it's a useful rule of thumb to me anyway.

 

[James Kuyper]

James Kuyper wrote: ....

Anything that is commonly described as evil usually has a more or less
reasonable explanation behind it. Simply declaring it beyond
understanding is, in my opinion, just not wanting to do your homework.

You equate describing something as "evil" with "declaring it beyond
understanding"? I don't. I can understand evil (not always, especially
in extreme cases - but often). I've wanted to commit evil, and have
occasionally failed to resist the temptation to do so. I understand why
others would be tempted to do evil, and why they sometimes give in.
There are many people whose acts have been far more evil than any that
I've ever committed or even been tempted to commit, but I'm intelligent
enough to extrapolate from my own experiences, with due attention to the
dangers of extrapolation. To me, calling something "evil" does not mark
it as beyond understanding, but only as seriously undesirable behavior,
whether or not it is well understood.