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
}
}
}

[Gianni Mariani]

Jordan wrote:

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.

[Victor Bazarov]

Jordan wrote:

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

[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]

Jordan wrote:

Victor,

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

Wrote what?
Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

[Jay Nabonne]

On Tue, 13 Dec 2005 11:48:09 -0800, Marcelo Pinto wrote:

[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]

Jay Nabonne wrote:

On Tue, 13 Dec 2005 11:48:09 -0800, Marcelo Pinto wrote:

[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]

Jordan wrote:

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::exce ption&) {
}

Or some variant thereof.

Regards,
Peter Jansson