Code Style - Handling Returns

[Jordan]

While writing some code, I realized I had never developed a consistent
pattern for checking errors from a method. I have two styles I jump
back and forth between, but I'm wondering which is better.

Scenario:
* In method that returns success/fail
* Call method that also returns success/fail
* Need to check return state and continue or exit outer method

I personally think Case 1 looks a little cleaner but it breaks more
than case 2. Any opinions?


Case 1:

bool flag = myFunc1( );
if( flag == false )
{
return;
}

flag = myFunc2( );
if( flag == false )
{
return;
}

// more code


Case 2:

bool flag = myFunc1( );
if( flag == true )
{
flag = myFunc2( );
if( flag == true )
{
flag = myFunc3( );
if( flag == true )
{
// continue code
}
}
}

 

[Victor Bazarov]

While writing some code, I realized I had never developed a consistent
pattern for checking errors from a method. I have two styles I jump
back and forth between, but I'm wondering which is better.

Regardless of your personal preference, writing

if (flag == false)

is silly. 'flag' already has type 'bool', so just write

if (!flag)

Same goes for

if (flag == true)

.. Just write

if (flag)

and drop the "== true" clutter.

Scenario:
* In method that returns success/fail
* Call method that also returns success/fail
* Need to check return state and continue or exit outer method

I personally think Case 1 looks a little cleaner but it breaks more
than case 2. Any opinions?


Case 1:

bool flag = myFunc1( );
if( flag == false )
{
return;
}

flag = myFunc2( );
if( flag == false )
{
return;
}

// more code


Case 2:

bool flag = myFunc1( );
if( flag == true )
{
flag = myFunc2( );
if( flag == true )
{
flag = myFunc3( );
if( flag == true )
{
// continue code
}
}
}

Neither is better than the other.

I prefer

if (!myFunc1() || !myFunc2())
return;
// continue code

V

 

[Gianni Mariani]

While writing some code, I realized I had never developed a consistent
pattern for checking errors from a method. I have two styles I jump
back and forth between, but I'm wondering which is better.

Scenario:
* In method that returns success/fail
* Call method that also returns success/fail
* Need to check return state and continue or exit outer method

I personally think Case 1 looks a little cleaner but it breaks more
than case 2. Any opinions?

I tend to prefer case 1 with RAII classes to handle cleanup which makes
it both exception safe and much less prone to error from code
maintenance adding a new if/return block.

 

[Marcelo Pinto]

[snip]

is silly. 'flag' already has type 'bool', so just write

if (!flag)

I personally prefer
if(not flag)
I always have some dificulty to see the _!_ operator when I am reading
code (specially when I am in a rush, which is almost always).

Regards,

Marcelo Pinto

 

[Jordan]

Victor,

I just wrote that for clarity for the group. Thanks.

 

[Jordan]

After putting some thought in this, it sounds like Gianni made a good
point that validating for failure after each call would be the better
approach since memory can be safely deallocated, messages logged, etc.
It also reads better on screen rather than having a deep nests.

And yes, I'm a strong believe in the '!'. Like I said earlier, I was
just trying to clarify for readability on the group board.

 

[Default User]

Victor,

I just wrote that for clarity for the group. Thanks.

Wrote what?


Brian

 

[Jay Nabonne]

[snip]

is silly. 'flag' already has type 'bool', so just write

if (!flag)

I personally prefer
if(not flag)
I always have some dificulty to see the _!_ operator when I am reading
code (specially when I am in a rush, which is almost always).

What is "not" in this example?

- Jay

 

[Victor Bazarov]

[snip]

is silly. 'flag' already has type 'bool', so just write

if (!flag)

I personally prefer
if(not flag)
I always have some dificulty to see the _!_ operator when I am reading
code (specially when I am in a rush, which is almost always).

What is "not" in this example?

Uh... It's a keyword, the alternative spelling for '!'. What else could
it be?

 

[Peter Jansson]

While writing some code, I realized I had never developed a consistent
pattern for checking errors from a method. I have two styles I jump
back and forth between, but I'm wondering which is better.

Scenario:
* In method that returns success/fail
* Call method that also returns success/fail
* Need to check return state and continue or exit outer method

I personally think Case 1 looks a little cleaner but it breaks more
than case 2. Any opinions?


Case 1:

bool flag = myFunc1( );
if( flag == false )
{
return;
}

flag = myFunc2( );
if( flag == false )
{
return;
}

// more code


Case 2:

bool flag = myFunc1( );
if( flag == true )
{
flag = myFunc2( );
if( flag == true )
{
flag = myFunc3( );
if( flag == true )
{
// continue code
}
}
}

Another track in this thread: How would instead like to use exception
handling? E.g.:

try {
myFunc1(); // Which may throw an exception if you desing it so.
myFunc2(); // Which may throw anonther exception.
myFunc3(); // Which may throw yet anonther exception.
// ... and so on
} catch(std::exception&) {
}

Or some variant thereof.

Regards,
Peter Jansson

 

[Victor Bazarov]

[...]
Another track in this thread: How would instead like to use exception
handling? E.g.:

try {
myFunc1(); // Which may throw an exception if you desing it so.
myFunc2(); // Which may throw anonther exception.
myFunc3(); // Which may throw yet anonther exception.
// ... and so on
} catch(std::exception&) {
}

Or some variant thereof.

There is a school of thought out there that strongly discourages
using exception handling to handle something that is normal. If the
purpose is to detect a normal condition (flag is set to false is not
an exceptional situation) and bail out earlier, exceptions may not be
the right tool.

I am sure you can find more on error code checking versus exception
handling in the archives.

V

 

[niklasb]

While writing some code, I realized I had never developed a consistent
pattern for checking errors from a method.

[snip]

Another track in this thread: How would instead like to use exception
handling? E.g.:

try {
myFunc1(); // Which may throw an exception if you desing it so.
myFunc2(); // Which may throw anonther exception.
myFunc3(); // Which may throw yet anonther exception.
// ... and so on
} catch(std::exception&) {
}

Or better yet,

myFunc1(); // may throw an exception
myFunc2(); // may also throw
myFunc3(); // ditto

// ... and so on ...
// no need for try/catch in most cases; local objects are
// destroyed regardless of how control leaves the current
// block; you did use RAII consistently, right?

 

[Jay Nabonne]

[snip]

is silly. 'flag' already has type 'bool', so just write

if (!flag)

I personally prefer
if(not flag)
I always have some dificulty to see the _!_ operator when I am reading
code (specially when I am in a rush, which is almost always).

What is "not" in this example?

Uh... It's a keyword, the alternative spelling for '!'. What else could
it be?

Well, my first thought was it was a Pascalian slip.

I've never seen "not" used in C++ code, and Visual Studio 7.1 doesn't like
it (not that that means anything). gcc does, so I guess I have learned
something new today.

Thanks.

- Jay

 

[Mike Wahler]

Wrote what?

Who said that?

Mike

 

[Marcus Kwok]

Well, my first thought was it was a Pascalian slip.

I've never seen "not" used in C++ code, and Visual Studio 7.1 doesn't like
it (not that that means anything). gcc does, so I guess I have learned
something new today.

On VS 7.1, you may need to #include <iso646.h> (or <ciso646> if you
prefer).

 

[Jordan]

Mike,

I was simply making a reference to Victor that originally asked my why
I displayed:

if( statement != true )

instead of

if( !statement )

I just mentioned that I normally do use '!' but I used the full
statement just for clarity purposes (also, I just finished writting
some c# code where the boolean check must be more explicit for 'true'
cases).

 

[Jordan]

Peter,

I have to agree with Victor on this one. Typically exceptions should
only be used for worst-case scenarios. I personally like to create an
enumerated error code field and pass error codes to an error manager
which can either output to display or log the error.

 

[Jordan]

Mike,

I was simply making a reference to ...

oh, scratch that. I'm a gimp.

 

[deane_gavin]

Peter,

I have to agree with Victor on this one. Typically exceptions should
only be used for worst-case scenarios. I personally like to create an
enumerated error code field and pass error codes to an error manager
which can either output to display or log the error.

I'm not sure you are agreeing with Victor, but that's just my
interpretation of what you and he said.

What do you mean by "worst-case scenarios"? A system of several
different error codes (each of which presumably can from different
parts of your code) being passed around until they can be given to an
error manager to handle sounds to me like a classic case where using
exceptions could make your code cleaner and easier to read.

Gavin Deane

 

[Jay Nabonne]

On VS 7.1, you may need to #include <iso646.h> (or <ciso646> if you
prefer).

That worked. Thanks!