Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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.
share|improve this question

marked as duplicate by gnat, Kilian Foth, MichaelT, GlenH7, Bart van Ingen Schenau Feb 28 at 11:29

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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 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 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 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 at 13:53
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 at 21:30

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer
1  
+1 for less identation. R# constatly nags about it and for good purpose. –  Florin Bombeanu Feb 26 at 13:22

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'.

share|improve this answer
    
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 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: stackoverflow.com/questions/175532/… –  Florin Bombeanu Feb 26 at 15:21
    
Thanks again, that's a good read indeed. –  Mahdi Feb 26 at 15:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.