Control Flow

    The first five control flow mechanisms are standard to high-level programming languages. Tasks are not so standard: they provide non-local control flow, making it possible to switch between temporarily-suspended computations. This is a powerful construct: both exception handling and cooperative multitasking are implemented in Julia using tasks. Everyday programming requires no direct usage of tasks, but certain problems can be solved much more easily by using tasks.

    Sometimes it is convenient to have a single expression which evaluates several subexpressions in order, returning the value of the last subexpression as its value. There are two Julia constructs that accomplish this: begin blocks and ; chains. The value of both compound expression constructs is that of the last subexpression. Here’s an example of a begin block:

    Since these are fairly small, simple expressions, they could easily be placed onto a single line, which is where the ; chain syntax comes in handy:

    1. julia> z = (x = 1; y = 2; x + y)
    2. 3

    This syntax is particularly useful with the terse single-line function definition form introduced in Functions. Although it is typical, there is no requirement that begin blocks be multiline or that ; chains be single-line:

    1. julia> begin x = 1; y = 2; x + y end
    2. 3
    4. julia> (x = 1;
    5.         y = 2;
    6.         x + y)
    7. 3

    Conditional Evaluation

    Conditional evaluation allows portions of code to be evaluated or not evaluated depending on the value of a boolean expression. Here is the anatomy of the if-elseif-else conditional syntax:

    1. if x < y
    2.     println("x is less than y")
    3. elseif x > y
    4.     println("x is greater than y")
    5. else
    6.     println("x is equal to y")
    7. end

    If the condition expression x < y is true, then the corresponding block is evaluated; otherwise the condition expression x > y is evaluated, and if it is true, the corresponding block is evaluated; if neither expression is true, the else block is evaluated. Here it is in action:

    1. julia> function test(x, y)
    2.            if x < y
    3.                println("x is less than y")
    4.            elseif x > y
    5.                println("x is greater than y")
    6.            else
    7.                println("x is equal to y")
    8.            end
    9.        end
    10. test (generic function with 1 method)
    12. julia> test(1, 2)
    13. x is less than y
    15. julia> test(2, 1)
    16. x is greater than y
    18. julia> test(1, 1)
    19. x is equal to y

    The elseif and else blocks are optional, and as many elseif blocks as desired can be used. The condition expressions in the if-elseif-else construct are evaluated until the first one evaluates to true, after which the associated block is evaluated, and no further condition expressions or blocks are evaluated.

    if blocks are “leaky”, i.e. they do not introduce a local scope. This means that new variables defined inside the if clauses can be used after the if block, even if they weren’t defined before. So, we could have defined the test function above as

    1. julia> function test(x,y)
    2.            if x < y
    3.                relation = "less than"
    4.            elseif x == y
    5.                relation = "equal to"
    6.            else
    7.                relation = "greater than"
    8.            end
    9.            println("x is ", relation, " y.")
    10.        end
    11. test (generic function with 1 method)
    13. julia> test(2, 1)
    14. x is greater than y.

    The variable relation is declared inside the if block, but used outside. However, when depending on this behavior, make sure all possible code paths define a value for the variable. The following change to the above function results in a runtime error

    1. julia> function test(x,y)
    2.            if x < y
    3.                relation = "less than"
    4.            elseif x == y
    5.                relation = "equal to"
    6.            end
    7.            println("x is ", relation, " y.")
    8.        end
    9. test (generic function with 1 method)
    11. julia> test(1,2)
    12. x is less than y.
    14. julia> test(2,1)
    15. ERROR: UndefVarError: relation not defined
    16. Stacktrace:
    17.  [1] test(::Int64, ::Int64) at ./none:7

    if blocks also return a value, which may seem unintuitive to users coming from many other languages. This value is simply the return value of the last executed statement in the branch that was chosen, so

    1. julia> x = 3
    2. 3
    4. julia> if x > 0
    5.            "positive!"
    6.        else
    7.            "negative..."
    8.        end
    9. "positive!"

    Note that very short conditional statements (one-liners) are frequently expressed using Short-Circuit Evaluation in Julia, as outlined in the next section.

    Unlike C, MATLAB, Perl, Python, and Ruby – but like Java, and a few other stricter, typed languages – it is an error if the value of a conditional expression is anything but true or false:

    1. julia> if 1
    2.            println("true")
    3.        end
    4. ERROR: TypeError: non-boolean (Int64) used in boolean context

    This error indicates that the conditional was of the wrong type: rather than the required Bool.

    The so-called “ternary operator”, ?:, is closely related to the if-elseif-else syntax, but is used where a conditional choice between single expression values is required, as opposed to conditional execution of longer blocks of code. It gets its name from being the only operator in most languages taking three operands:

    1. a ? b : c

    The expression a, before the ?, is a condition expression, and the ternary operation evaluates the expression b, before the :, if the condition a is true or the expression c, after the :, if it is false. Note that the spaces around ? and : are mandatory: an expression like a?b:c is not a valid ternary expression (but a newline is acceptable after both the ? and the :).

    The easiest way to understand this behavior is to see an example. In the previous example, the println call is shared by all three branches: the only real choice is which literal string to print. This could be written more concisely using the ternary operator. For the sake of clarity, let’s try a two-way version first:

    1. julia> x = 1; y = 2;
    3. julia> println(x < y ? "less than" : "not less than")
    4. less than
    6. julia> x = 1; y = 0;
    8. julia> println(x < y ? "less than" : "not less than")
    9. not less than

    If the expression x < y is true, the entire ternary operator expression evaluates to the string "less than" and otherwise it evaluates to the string "not less than". The original three-way example requires chaining multiple uses of the ternary operator together:

    1. julia> test(x, y) = println(x < y ? "x is less than y"    :
    2.                             x > y ? "x is greater than y" : "x is equal to y")
    3. test (generic function with 1 method)
    5. julia> test(1, 2)
    6. x is less than y
    8. julia> test(2, 1)
    9. x is greater than y
    11. julia> test(1, 1)
    12. x is equal to y

    To facilitate chaining, the operator associates from right to left.

    It is significant that like if-elseif-else, the expressions before and after the : are only evaluated if the condition expression evaluates to true or false, respectively:

    1. v (generic function with 1 method)
    3. julia> 1 < 2 ? v("yes") : v("no")
    4. yes
    5. "yes"
    7. julia> 1 > 2 ? v("yes") : v("no")
    8. no

    The && and || operators in Julia correspond to logical “and” and “or” operations, respectively, and are typically used for this purpose. However, they have an additional property of short-circuit evaluation: they don’t necessarily evaluate their second argument, as explained below. (There are also bitwise & and | operators that can be used as logical “and” and “or” without short-circuit behavior, but beware that & and | have higher precedence than && and || for evaluation order.)

    Short-circuit evaluation is quite similar to conditional evaluation. The behavior is found in most imperative programming languages having the && and || boolean operators: in a series of boolean expressions connected by these operators, only the minimum number of expressions are evaluated as are necessary to determine the final boolean value of the entire chain. Some languages (like Python) refer to them as and (&&) and or (||). Explicitly, this means that:

    • In the expression a && b, the subexpression b is only evaluated if a evaluates to true.
    • In the expression a || b, the subexpression b is only evaluated if a evaluates to false.

    The reasoning is that a && b must be false if a is false, regardless of the value of b, and likewise, the value of a || b must be true if a is true, regardless of the value of b. Both && and || associate to the right, but && has higher precedence than || does. It’s easy to experiment with this behavior:

    You can easily experiment in the same way with the associativity and precedence of various combinations of && and || operators.

    For example, a recursive factorial routine could be defined like this:

    1. julia> function fact(n::Int)
    2.            n >= 0 || error("n must be non-negative")
    3.            n == 0 && return 1
    4.            n * fact(n-1)
    5.        end
    6. fact (generic function with 1 method)
    8. julia> fact(5)
    9. 120
    11. julia> fact(0)
    12. 1
    14. julia> fact(-1)
    15. ERROR: n must be non-negative
    16. Stacktrace:
    17.  [1] error at ./error.jl:33 [inlined]
    18.  [2] fact(::Int64) at ./none:2
    19.  [3] top-level scope

    Boolean operations without short-circuit evaluation can be done with the bitwise boolean operators introduced in Mathematical Operations and Elementary Functions: & and |. These are normal functions, which happen to support infix operator syntax, but always evaluate their arguments:

    1. julia> f(1) & t(2)
    2. 1
    3. 2
    4. false
    6. julia> t(1) | t(2)
    7. 1
    8. 2
    9. true

    Just like condition expressions used in if, elseif or the ternary operator, the operands of && or || must be boolean values (true or false). Using a non-boolean value anywhere except for the last entry in a conditional chain is an error:

    1. julia> 1 && true
    2. ERROR: TypeError: non-boolean (Int64) used in boolean context

    On the other hand, any type of expression can be used at the end of a conditional chain. It will be evaluated and returned depending on the preceding conditionals:

    1. julia> true && (x = (1, 2, 3))
    2. (1, 2, 3)
    4. julia> false && (x = (1, 2, 3))
    5. false

    Repeated Evaluation: Loops

    There are two constructs for repeated evaluation of expressions: the while loop and the for loop. Here is an example of a while loop:

    1. julia> i = 1;
    3. julia> while i <= 5
    4.            println(i)
    5.            global i += 1
    6.        end
    7. 1
    8. 2
    9. 3
    10. 4
    11. 5

    The while loop evaluates the condition expression (i <= 5 in this case), and as long it remains true, keeps also evaluating the body of the while loop. If the condition expression is false when the while loop is first reached, the body is never evaluated.

    The for loop makes common repeated evaluation idioms easier to write. Since counting up and down like the above while loop does is so common, it can be expressed more concisely with a for loop:

    1. julia> for i = 1:5
    2.            println(i)
    3.        end
    4. 1
    5. 2
    6. 3
    7. 4
    8. 5

    Here the 1:5 is a range object, representing the sequence of numbers 1, 2, 3, 4, 5. The for loop iterates through these values, assigning each one in turn to the variable i. One rather important distinction between the previous while loop form and the for loop form is the scope during which the variable is visible. If the variable i has not been introduced in another scope, in the for loop form, it is visible only inside of the for loop, and not outside/afterwards. You’ll either need a new interactive session instance or a different variable name to test this:

    1. julia> for j = 1:5
    2.            println(j)
    3.        end
    4. 1
    5. 2
    6. 3
    7. 4
    8. 5
    10. julia> j
    11. ERROR: UndefVarError: j not defined

    See for a detailed explanation of variable scope and how it works in Julia.

    In general, the for loop construct can iterate over any container. In these cases, the alternative (but fully equivalent) keyword in or ∈ is typically used instead of =, since it makes the code read more clearly:

    1. julia> for i in [1,4,0]
    2.            println(i)
    3.        end
    4. 1
    5. 4
    6. 0
    8. julia> for s ∈ ["foo","bar","baz"]
    9.            println(s)
    10.        end
    11. foo
    12. bar
    13. baz

    Various types of iterable containers will be introduced and discussed in later sections of the manual (see, e.g., Multi-dimensional Arrays).

    It is sometimes convenient to terminate the repetition of a while before the test condition is falsified or stop iterating in a for loop before the end of the iterable object is reached. This can be accomplished with the break keyword:

    1. julia> i = 1;
    3. julia> while true
    4.            println(i)
    5.            if i >= 5
    6.                break
    7.            end
    8.            global i += 1
    9.        end
    10. 1
    11. 2
    12. 3
    13. 4
    14. 5
    16. julia> for j = 1:1000
    17.            println(j)
    18.            if j >= 5
    19.                break
    20.            end
    21.        end
    22. 1
    23. 2
    24. 3
    26. 5

    Without the break keyword, the above while loop would never terminate on its own, and the for loop would iterate up to 1000. These loops are both exited early by using break.

    In other circumstances, it is handy to be able to stop an iteration and move on to the next one immediately. The continue keyword accomplishes this:

    1. julia> for i = 1:10
    2.            if i % 3 != 0
    3.                continue
    4.            println(i)
    5.        end
    6. 3
    7. 6
    8. 9

    This is a somewhat contrived example since we could produce the same behavior more clearly by negating the condition and placing the println call inside the if block. In realistic usage there is more code to be evaluated after the continue, and often there are multiple points from which one calls continue.

    Multiple nested for loops can be combined into a single outer loop, forming the cartesian product of its iterables:

    1. julia> for i = 1:2, j = 3:4
    2.            println((i, j))
    3.        end
    4. (1, 3)
    5. (1, 4)
    6. (2, 3)
    7. (2, 4)

    With this syntax, iterables may still refer to outer loop variables; e.g. for i = 1:n, j = 1:i is valid. However a break statement inside such a loop exits the entire nest of loops, not just the inner one. Both variables (i and j) are set to their current iteration values each time the inner loop runs. Therefore, assignments to i will not be visible to subsequent iterations:

    1. julia> for i = 1:2, j = 3:4
    2.            println((i, j))
    3.            i = 0
    4.        end
    5. (1, 3)
    6. (1, 4)
    7. (2, 3)
    8. (2, 4)

    If this example were rewritten to use a for keyword for each variable, then the output would be different: the second and fourth values would contain 0.

    Multiple containers can be iterated over at the same time in a single for loop using :

    Using zip will create an iterator that is a tuple containing the subiterators for the containers passed to it. The zip iterator will iterate over all subiterators in order, choosing the $i$th element of each subiterator in the $i$th iteration of the for loop. Once any of the subiterators run out, the for loop will stop.

    When an unexpected condition occurs, a function may be unable to return a reasonable value to its caller. In such cases, it may be best for the exceptional condition to either terminate the program while printing a diagnostic error message, or if the programmer has provided code to handle such exceptional circumstances then allow that code to take the appropriate action.

    Exceptions are thrown when an unexpected condition has occurred. The built-in Exceptions listed below all interrupt the normal flow of control.

    For example, the function throws a DomainError if applied to a negative real value:

    1. julia> sqrt(-1)
    2. ERROR: DomainError with -1.0:
    3. sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)).
    4. Stacktrace:
    5. [...]
    1. julia> struct MyCustomException <: Exception end

    Exceptions can be created explicitly with throw. For example, a function defined only for nonnegative numbers could be written to a DomainError if the argument is negative:

    1. julia> f(x) = x>=0 ? exp(-x) : throw(DomainError(x, "argument must be nonnegative"))
    2. f (generic function with 1 method)
    4. julia> f(1)
    5. 0.36787944117144233
    7. julia> f(-1)
    8. ERROR: DomainError with -1:
    9. argument must be nonnegative
    10. Stacktrace:
    11.  [1] f(::Int64) at ./none:1

    Note that without parentheses is not an exception, but a type of exception. It needs to be called to obtain an Exception object:

    1. julia> typeof(DomainError(nothing)) <: Exception
    2. true
    4. julia> typeof(DomainError) <: Exception
    5. false

    Additionally, some exception types take one or more arguments that are used for error reporting:

    1. julia> throw(UndefVarError(:x))
    2. ERROR: UndefVarError: x not defined

    This mechanism can be implemented easily by custom exception types following the way UndefVarError is written:

    1. julia> struct MyUndefVarError <: Exception
    2.            var::Symbol
    3.        end
    5. julia> Base.showerror(io::IO, e::MyUndefVarError) = print(io, e.var, " not defined")

    Note

    When writing an error message, it is preferred to make the first word lowercase. For example,

    size(A) == size(B) || throw(DimensionMismatch("size of A not equal to size of B"))

    is preferred over

    size(A) == size(B) || throw(DimensionMismatch("Size of A not equal to size of B")).

    However, sometimes it makes sense to keep the uppercase first letter, for instance if an argument to a function is a capital letter:

    size(A,1) == size(B,2) || throw(DimensionMismatch("A has first dimension...")).

    The error function is used to produce an that interrupts the normal flow of control.

    Suppose we want to stop execution immediately if the square root of a negative number is taken. To do this, we can define a fussy version of the sqrt function that raises an error if its argument is negative:

    1. julia> fussy_sqrt(x) = x >= 0 ? sqrt(x) : error("negative x not allowed")
    2. fussy_sqrt (generic function with 1 method)
    4. julia> fussy_sqrt(2)
    5. 1.4142135623730951
    7. julia> fussy_sqrt(-1)
    8. ERROR: negative x not allowed
    9. Stacktrace:
    10.  [1] error at ./error.jl:33 [inlined]
    11.  [2] fussy_sqrt(::Int64) at ./none:1
    12.  [3] top-level scope

    If fussy_sqrt is called with a negative value from another function, instead of trying to continue execution of the calling function, it returns immediately, displaying the error message in the interactive session:

    1. julia> function verbose_fussy_sqrt(x)
    2.            println("before fussy_sqrt")
    3.            r = fussy_sqrt(x)
    4.            println("after fussy_sqrt")
    5.            return r
    6.        end
    7. verbose_fussy_sqrt (generic function with 1 method)
    9. julia> verbose_fussy_sqrt(2)
    10. before fussy_sqrt
    11. after fussy_sqrt
    12. 1.4142135623730951
    14. julia> verbose_fussy_sqrt(-1)
    15. before fussy_sqrt
    16. ERROR: negative x not allowed
    17. Stacktrace:
    18.  [1] error at ./error.jl:33 [inlined]
    19.  [2] fussy_sqrt at ./none:1 [inlined]
    20.  [3] verbose_fussy_sqrt(::Int64) at ./none:3
    21.  [4] top-level scope

    The try/catch statement allows for Exceptions to be tested for, and for the graceful handling of things that may ordinarily break your application. For example, in the below code the function for square root would normally throw an exception. By placing a try/catch block around it we can mitigate that here. You may choose how you wish to handle this exception, whether logging it, return a placeholder value or as in the case below where we just printed out a statement. One thing to think about when deciding how to handle unexpected situations is that using a try/catch block is much slower than using conditional branching to handle those situations. Below there are more examples of handling exceptions with a try/catch block:

    1. julia> try
    2.            sqrt("ten")
    3.        catch e
    4.            println("You should have entered a numeric value")
    5.        end
    6. You should have entered a numeric value

    try/catch statements also allow the Exception to be saved in a variable. The following contrived example calculates the square root of the second element of x if x is indexable, otherwise assumes x is a real number and returns its square root:

    1. julia> sqrt_second(x) = try
    2.            sqrt(x[2])
    3.        catch y
    4.            if isa(y, DomainError)
    5.                sqrt(complex(x[2], 0))
    6.            elseif isa(y, BoundsError)
    7.                sqrt(x)
    8.            end
    9.        end
    10. sqrt_second (generic function with 1 method)
    12. julia> sqrt_second([1 4])
    13. 2.0
    15. julia> sqrt_second([1 -4])
    16. 0.0 + 2.0im
    18. julia> sqrt_second(9)
    19. 3.0
    21. julia> sqrt_second(-9)
    22. ERROR: DomainError with -9.0:
    23. sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)).
    24. Stacktrace:
    25. [...]

    Note that the symbol following catch will always be interpreted as a name for the exception, so care is needed when writing try/catch expressions on a single line. The following code will not work to return the value of x in case of an error:

    1. try bad() catch x end

    Instead, use a semicolon or insert a line break after catch:

    1. try bad() catch; x end
    3. try bad()
    4. catch
    5. end

    The power of the try/catch construct lies in the ability to unwind a deeply nested computation immediately to a much higher level in the stack of calling functions. There are situations where no error has occurred, but the ability to unwind the stack and pass a value to a higher level is desirable. Julia provides the rethrow, , catch_backtrace and functions for more advanced error handling.

    In code that performs state changes or uses resources like files, there is typically clean-up work (such as closing files) that needs to be done when the code is finished. Exceptions potentially complicate this task, since they can cause a block of code to exit before reaching its normal end. The finally keyword provides a way to run some code when a given block of code exits, regardless of how it exits.

    For example, here is how we can guarantee that an opened file is closed:

    When control leaves the try block (for example due to a return, or just finishing normally), close(f) will be executed. If the try block exits due to an exception, the exception will continue propagating. A catch block may be combined with try and finally as well. In this case the finally block will run after has handled the error.

    Tasks (aka Coroutines)

    Tasks are a control flow feature that allows computations to be suspended and resumed in a flexible manner. We mention them here only for completeness; for a full discussion see .