Use A Return Statement When Invoking Callbacks, Especially In A Guard Statement
In a synchronous processing workflow, the Return statement tends to indicates the end of a given function's execution. In an asynchronous processing workflow, callbacks are more generally used to indicate the desired end of a given function's execution. That said, it is critical that a Return statement is also used in an asynchronous workflow in order to ensure that multiple callbacks are not invoked accidentally. This is a mistake that I have made many times and it always comes back to bite me.
In a synchronous workflow, when a function exits, it returns control to the calling context. This allows the Return statement to act as the primary indicator of a function's outcome. To understand this, take a look at the following demo in which a function's Guard statement allows for an early return / termination of the function execution:
<!DOCTYPE html>
<html>
<head>
<title>Using Return Statements In Guard Logic</title>
<script type="text/javascript">
// A simple method including guard logic.
var doSomething = function(){
// Check some guard logic.
if (true === true){
// Return out of function exection since some
// condition indicates that the rest of the
// method should not be invoked.
return;
}
// If we made it this far, all of the guard logic
// indicated that we are good to go on execution.
return;
};
// Invoke our guarded method.
doSomething();
</script>
</head>
<body>
<!-- Left intentionally blank. -->
</body>
</html>
This code is probably very familiar to you - it simply allows multiple exit points in a synchronous workflow.
As we move into a more asynchronous environment, whether it be on the Client with something like jQuery Deferred objects, or on the Server with something like Node.js, we typically need to take a more callback-oriented approach to function termination. Since asynchronous methods take place outside of the "calling context" workflow, a return statement no longer returns control to the appropriate part of the stack.
With this mental shift, I often forget to use a Return statement - I often use the callback invocation as a return-substitution:
<!DOCTYPE html>
<html>
<head>
<title>Using Return Statements When Invoking Callbacks</title>
<script type="text/javascript">
// Define a success handler.
var successHandler = function(){
console.log( "Success!" );
};
// Define a fail handler.
var failHandler = function(){
console.log( "Fail :(" );
};
// Now, let's create a mock function that makes use of the
// success and fail callback handlers.
var doSomething = function( successHandler, failHandler ){
// Check to see if some value is true - for a mock
// fail handler invocation.
if (true === true){
failHandler();
}
// If we made it this far, then everything executed
// well - invoke success handler.
successHandler();
};
/// Invoke the callback-oriented method.
doSomething( successHandler, failHandler );
</script>
</head>
<body>
<!-- Left intentionally blank. -->
</body>
</html>
Here, you can see that my asynchronous workflow has a similar setup to my synchronous workflow: I have a function, doSomething(), that contains a guard statement and two "exit" points - one for success and one for failure. When we run this code, however, we get an unexpected console output:
Fail :(
Success!
As you can see, both my fail and my success handler executed. This is because I mistakenly substituted my synchronous Return statements with my asynchronous callbacks.
In reality, the shift from synchronous to asynchronous control flow is not one of "substitution," but rather of "augmentation." Callbacks don't replace our Return statements - they augment them. In order to get this asynchronous code to act appropriately, I have to use both a return statement and a callback invocation:
<!DOCTYPE html>
<html>
<head>
<title>Using Return Statements When Invoking Callbacks</title>
<script type="text/javascript">
// Define a success handler.
var successHandler = function(){
console.log( "Success!" );
};
// Define a fail handler.
var failHandler = function(){
console.log( "Fail :(" );
};
// Now, let's create a mock function that makes use of the
// success and fail callback handlers.
var doSomething = function( successHandler, failHandler ){
// Check to see if some value is true - for a mock
// fail handler invocation.
if (true === true){
return( failHandler() );
}
// If we made it this far, then everything executed
// well - invoke success handler.
return( successHandler() );
};
/// Invoke the callback-oriented method.
doSomething( successHandler, failHandler );
</script>
</head>
<body>
<!-- Left intentionally blank. -->
</body>
</html>
Here, you can see that both of my callback invocations are wrapped in a return statement in the form of:
return( failHandler() );
Now, when I run the above code, I get the appropriate console output:
Fail :(
As you can see, the return() statement defined the technical termination of the function after the callback invocation defined the "intended" termination of the function.
Technically, the return() statement is only required within the guard statement; however, forgetting to use return() is a mistake that I make often. As such, I try to use return() statements with all of my callback invocations as a means to drill the concept into my head.
Want to use code from this post? Check out the license.
Reader Comments
So this will just show that I learned old time procedural programming, but I always create a return variable and set that in the various parts of the function. Then I return the variable at the end of the function.
One entry point, one exit point. Today's programmers use exit points like old programmers used GOTOs... poorly.
Believe it or not I've helped a lot of people to fix problems with their stuff just by forcing them to use one entry, one exit.
@Steve,
I think using a single Return statement at the end of your function works well because it is a "rule." I'm not sure there is anything implicitly more valuable about it other than that. After all, the placement of a return variable doesn't shed any insight into where / how that variable was set until you actually read through the code.
The reasons I make mistakes with the callbacks is not because they are mid-function - it's because I didn't really have a "rule" about how to use them. As long as I am dedicated to wrapping my callback invocation in return(), then I think I should only incur the same problems that setting a return variable would incur.
As with all things, I think errors are minimized as long as you are cognizant and mindful about your approach. Then, whichever approach you use becomes less of an issue.
This could be simpler and easier to read using a Ternary operation.
@David,
Can you expand on that? I am not sure what you mean?
var successHandler = function(){
document.write( "Success!" );
};
// ------ Define a fail handler.
var failHandler = function(){
document.write( "Fail" );
};
// ------ Now, let's create a mock function that makes use of the success and fail callback handlers.*/
var doSomething = function( successHandler, failHandler ){
1===1 ? failHandler() : successHandler() ;
};
// ------ Invoke the callback-oriented method.
doSomething( successHandler, failHandler );
@David,
Ah, I see what you're saying. Definitely, if it came down to simply calling one or the other, the ternary operator would be nice.
Technically, the ternary operator suggests there are only two possible conditions. You define a predicate, the consequent, and the ONLY alternative. If there were more than one alternative, you would wish to use a switch-case or if-else. Your approach could become unwieldy if new logic was introduced, because you have multiple returns that end the Flow.
For example:
if (1===1)
{
continue
} else {
return; //stop the flow
}
//throw new Error();
By suggesting there are alternative conditions, when someone else comes along and adds to the method body, condition 1 will allow the code to run and the throw to get called. Condition 2 will execute the return. If you only have two possible conditions, the ternary operator helps to enforce the logic.
I guess the example is weird in that it returns a function, too. you're returning a method you are invoking, too. You want to call the function and end the operation. Yet, there is 1 consequent and one alternative, so why call a return?
return ((true === true) ? failHandler() : successHandler());
Actually, I messed up:
true === true ? successHandler() : failHandler());