Return statement

From Wikipedia, the free encyclopedia

This article does not cite any references or sources. (March 2008) Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

In computer programming, a return statement causes execution to leave the current subroutine and resume at the point the subroutine was called -- known as its return address. The return address is saved, usually on the process's call 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++, 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. In Windows 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.

[edit] Syntax

Return statements come in many shapes. The following syntaxes are most common:

As used in C, C++, Java, PHP, C#, Windows PowerShell:

return value;

As used in Smalltalk:

^ value

As used in Lisp:

(return value)

As used in BASIC:

RETURN

As used in Visual Basic .NET

Return Value

[edit] Criticism

^[who?](Some developers and computer programming educators) eschew 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,^[who?](Other developers) consider the return statement 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.