A question of indentation!

[Tomasz Sowinski]

Ok, ok, you've got me. But rules are made to break them, right? :-D Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

[Hans Dietrich]

Basically, what you want to do is call bunch of functions one after the other, but stop calling them once you get error. Here is code that will do that: BOOL rc = TRUE; if (rc) rc = rc && call1(); if (rc) rc = rc && call2(); if (rc) rc = rc && call3(); ... if (!rc) { // error handling code } else { // continue processing } You can use for any kind of sequential processing of functions, testing flags, etc. Best wishes, Hans

[Brit]

Then why not this?

if(!call1())
{
// cleanup
return;
}
if(!call2())
{
// cleanup
return;
}
if(!call3())
{
// cleanup
return;
}

Or:

if(!call1())
{
cleanup1();
return;
}
if(!call2())
{
cleanup2();
cleanup1();
return;
}
if(!call3())
{
cleanup3();
cleanup2();
cleanup1();
return;
}

[Alexandru Savescu]

:cool: Best regards, Alexandru Savescu

[Tomasz Sowinski]

You can remove && from expressions and use rc = callN() only. After all, this is executed only if rc is true - you're testing this condition few cycles before rc = rc && callN(). Tomasz Sowinski -- http://www.shooltz.com

- It's for protection
- Protection from what? Zee Germans?

[Christian Graus]

Jason Henderson wrote: Is Stroustrup trying to say it should only be used as a return mechanism if it isn't used in error handling? He's saying it's a valid way to control program flow, although it will most often be used to catch errors. He's suggesting that we not limit our thinking to error handling, because it can be used in other ways as well, which really are up to us as developers. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002

[Christian Graus]

Eddie Velasquez wrote: I'm not really thinking about this too hard, but I fail to come up with a case where I would raise an exception that doesn't somehow indicate an error condition. Most arguments people put forth for the use of goto are better controlled with try/catch, of the type where multiple points in the code can branch to the same block at the bottom. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002

[Jonathan Gilligan]

This kind of thing does indeed get ugly, but there's more to solving it than indentation. It's hard to keep straight how deep you are into the nested if statements. Better to break out and write something like this:

bool ok(true);

ok = call1();
if (ok)
ok = call2();
if (ok)
ok = call3();
...

The bool variable doesn't hurt performance noticeably (the compiler will optimize it out anyway, when you compile for release), and it makes the whole thing much more readable.

[Nish Nishant]

Nice and simple solution. Thanks :-) Nish

---

Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.

[Oliver Anhuth]

Hello Nish, in such cases I prefer the following indention style:

int result;

result = call1();
if (result)
{
result = call2();
}

if (result)
{
result = call3();
}

if (result)
{
result = call4();
}

and so on. This may take getting used to, but it keeps the indention level constant. regards Oliver

[Len Holgate]

Nish - Native CPian wrote: The problem is that each of these functions require something from the previous function. For example if fn_1 allocs something, then fn_2 uses that and allocs something else used by fn_3 and so on. On failure at any point I also have to call the respective deallocing PGP functions in reverse order That's the point. If you need to allocate a resource you do so in the constructor, you then use the resource, perhaps to allocate another resource, and release it in the destructor, hence you end up with code like:

CUsesPGP usesPGP(initStuff);

CPGPProvider provider("MyProvider");

CPGPKey key provider.GetKey("Blah");

CPGPData data(pData, length);

data.Encrypt(key);

The c++ class construction order makes sure that the resources are released correctly even if an exception is thrown. Methods throw exceptions so that the user cant ignore errors by default. The code is pretty much self documenting so you dont need huge comment blocks that get out of date. Oh, and it fixes your indentation problem... Len Holgate www.jetbyte.com The right code, right now.