Do you consider this technique “BAD”?

Question

Sometimes you need to skip execution of part of a method under certain non-critical error conditions. You can use exceptions for that, but exceptions generally are not

Answer 1

Split your code into smaller chunks of functional elements - so you could split the above into a function that returns instead of breaking.

I don't know if the above is bad practice but it's readability is a little off and may be confusing to others who might have to maintain the source.

Answer 2

This is convoluted and confusing, I would scrap it immediately.

Consider this alternative:

private void DoSomething()
{
   // some code
   if (some condition)
   {
      return;
   }
   // some more code
   if (some other condition)
   {
      return;
   }
   // yet more code
}

Also consider breaking up the code above into more than one method.

Answer 3

Basically you just described goto. I use goto in C all the time. I don't consider it bad, unless you use it to emulate a loop (never ever do that!). My typical usage of goto in C is to emulate exceptions (C has no exceptions):

// Code

if (bad_thing_happened) goto catch;

// More code

if (bad_thing_happened) goto catch;

// Even more code

finally:

// This code is executed in any case
// whether we have an exception or not,
// just like finally statement in other
// languages

return whatever;

catch:

// Code to handle bad error condition

// Make sure code tagged for finally
// is executed in any case
goto finally;

Except for the fact that catch and finally have opposite order, I fail to see why this code should be BAD just because it uses goto, if a real try/catch/finally code works exactly like this and just doesn't use goto. That makes no sense. And thus I fail to see why your code should be tagged as BAD.

Answer 4

I have no problem with that as long as the code is readable.

Answer 5

It depends on what the alternatives are. You have to admit that the code you posted is somewhat ugly. I wouldn't say it's clear. It's a kind of a hack. So if using some other coding solution would be worse, then ok. But if you have better alternative, don't let the excuse "it's good enough" comfort you.

Answer 6

public bool Method1(){ ... }
public bool Method2(){ ... }

public void DoStuff(){
    bool everythingWorked = Method1() && Method2();
    ... stuff you want executed always ...
}

The reason why this works is due to something called short circuit logic. Method2 won't be called if Method1 returns false.

This also has the additional benefit that you can break your method into smaller chunks, which will be easier to unit test.