0

I recently tend to design my methods in the following way:

if ( 'A' === $a ) {
    if ( 'B' === $b ) {
        return 'some thing';
    } else if ( 'C' === $c ) {
        return 'some other things';
    }
}

/* If you made it up to here, then something has gone wrong */
return false;

So basically the idea is to check if the first condition is correct, if it is then continue until you reach the first return statement to return the expected result, if not, move on to the next condition and so on.

The key is that all the method's functionality has already shrunken down and wrapped up in a conditional statement piece by piece, so you should meet at least one condition to take a useful action or if you reach the very last line, then it will return false, that means none of the expected conditions were met, that in my design it means the input wasn't in a proper or expected format, data-type, range, etc. so the method were not able to continue processing that.

I can achieve the same goal in a couple of different ways, but this one seems to be cleaner as I generally need to write code only for positive conditions (I actually don't know how should I call it) -- unless I need to take a specific action if a certain condition haven't met. And in the end I will get false if the method wasn't able to accomplish its job -- with real conditions in place most of the time it's almost like a jump to the end of method when you can't pass through an if statement. It's actually designed in a way that you will either pass this if and will heading to the either next if or a return statement or you are very unlikely to match any other if statements and will jump directly to the last return false statement.

Now, my questions are:

  1. Is it a (true) fail-fast design, which in this case is only looking for the proper condition to continue and is willing to fail as soon as one fails. Is that correct or am I mixing up things here? If not, is there any specific term for that?
  2. Also as I recently generalized this approach for all the new methods I create, I wish to know if there is any drawback or design flaw here that might bite me back later.
Mahdi
  • 1,983
  • 2
  • 15
  • 25
  • 1
    Failing fast is more about code that reports problems as soon as it can. The structure of that code isn't really relevant to the concept. – Blrfl Feb 26 '14 at 13:19
  • @gnat Thanks a lot for the links, that's what I was looking for. I didn't know that it is an anti-pattern and also it has a name `arrow head`. It will be great if you post it as answer also, I can at least up vote. – Mahdi Feb 26 '14 at 13:35
  • @Blrfl I totally agree, however as I'm new to the concept I wanted to know if it is a correct implementation or not. – Mahdi Feb 26 '14 at 13:37
  • 1
    Your implementation is fail-fast in the sense that it returns an error immediately after detecting the error condition. I suspect the question you may really be wanting to ask is "What's the best way to structure my code when detecting errors and failing fast?" JanHudec's answer is one possibility, but that structure won't work when you're using a language that doesn't have a `return` statement or working under a standard like MISRA that mandates single entry/return. – Blrfl Feb 26 '14 at 13:53
  • @Blrfl Thanks again for the further explanation. I have seen some developers really believe that single entry/return is a must, so in those cases this clearly won't work. Is there any specific solution you can offer just off the top of your mind, just for the further read on a more general fail-fast design? Thanks. – Mahdi Feb 26 '14 at 15:21
  • 1
    SE/SR works in some cases and can make for tortured-looking code in others. As for further reading, I can't recommend anything. Fail-fast is a simple concept, although I wouldn't be surprised if someone's managed to publish a 500-page book on it. – Blrfl Feb 26 '14 at 21:30

2 Answers2

7

A Fail-fast design is really the same structure but with reverse order to avoid the arrowhead code.

A fail fast design would be:

if ( 'A' !== $a )
    return false;

if ( 'B' === $b ) {
    return 'some thing';
}
if ( 'C' === $c ) {
    return 'some other things';
}
return false;

Less indentation is a good thing.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
1

Regarding your second question, my 2 cents are that your methods should not return anything if the input was not in the correct/expected format. Don't be afraid to use exceptions for expressing something like 'i cannot work with this input'.

Florin Bombeanu
  • 131
  • 4
  • Thanks for the answer. `Exceptions` look a bit of overkill to me in this case, however is there any other reason for avoiding the use of `return`? – Mahdi Feb 26 '14 at 13:40
  • The main reason is that it may not actually reflect an accurate result. It all comes down to the purpose of the method. This is a great read that might help: http://stackoverflow.com/questions/175532/should-a-retrieval-method-return-null-or-throw-an-exception-when-it-cant-prod – Florin Bombeanu Feb 26 '14 at 15:21