- Return statement
In
computer programming , a return statement causes execution to leave the currentsubroutine and resume at the point in the code immediately after where the subroutine was called -- known as its return address. The return address is saved, usually on the process'scall stack , as part of the operation of making the subroutine call. Return statements in many languages allow a function to specify a return value to be passed back to the code that called the function.In C/
C++ ,return "exp";
(where"exp"
is an expression) is a statement that tells a function to return execution of the program to the calling function, and report the value of"exp"
. If a function does not have a return type (i.e., its return type is void), the return statement can be used without a value, in which case the program just breaks out of the current function and returns to the calling one.In Pascal there is no return statement. A subroutine automatically returns when execution reaches its last executable statement. Values may be returned by assigning to an identifier that has the same name as the subroutine (a "function" in Pascal terminology).
Certain programming languages, such as
Perl and Ruby allow the programmer to omit an explicit return statement, specifying instead that the last evaluated expression is the return value of the subroutine. InWindows PowerShell all evaluated expressions which are not captured (e.g. assigned to a variable, cast to void or piped to $null) are returned from the subroutine as elements in an array, or as a single object in the case that only one object has not been captured.Values returned by the program when it terminates are often captured by batch programs.
Syntax
Return statements come in many shapes. The following syntaxes are most common:
As used in Ada, C,
C++ , Java,PHP , C#,Windows PowerShell :As used in
Smalltalk :As used in Lisp:
As used in
BASIC :As used in
Visual Basic .NET Criticism
It can be argued that one should eschew the use of the explicit return statement except at the textual end of a subroutine - considering that, when it is used to "return early", it suffers from the same sort of readability problems as the
GOTO statement. As with GOTO, there is a problem that in later development, a return statement could be overlooked by a developer, and an action which should be performed at the end of a subroutine (e.g.: a trace statement) might not be performed (in all cases).Conversely, it can be argued that using the return statement is worthwhile when the alternative is more convoluted code, harming readability.
It is generally accepted that the return statement should not be considered as harmful as GOTO, since it only allows jumping to one particular place in the subroutine. Moreover, in popular contemporary programming languages, the return value of a function is usually explicitly specified in the return statement.
Also, in languages such as Java, the "try..finally" construct can be used to always perform an action at the very end of a subroutine, after any return instruction has been executed. The finally clause will be executed even if an exception has been thrown (the exception is automatically caught, and then re-thrown after the finally clause has been executed, unless the finally clause "itself" throws an exception). When used appropriately (e.g. for closing file handles), this avoids the need to either find all exit points and add redundant statements immediately before them, or to refactor the subroutine to remove return statements - both of which are potentially error-prone procedures.
Aspect-oriented programming can also be used to do a similar job to "try..finally" - with or without the automatic exception-catching behaviour - although it is intended more to concisely express behaviours which "crosscut" more than one subroutine.ee also
*
Exit status
Wikimedia Foundation. 2010.