https://thatthinginswift.com/guard-statement-swift/
WHY USE GUARD?
Let’s take a look at a simple example comparing the old techniques vs using the guard statement:
|
1 2 3 4 5 6 7 8 9 |
func fooManualCheck(x: Int?) { if x == nil || x <= 0 { // Value requirements not met, do something return } // Do stuff with x x!.description } |
This is the most basic Objective-C style way to make sure a value exists and that it meets a condition.
Now this works fine, but has a couple flaws:
You’re checking for a condition that you don’t want, rather than checking for the value you do want.
Code becomes confusing when you have a bunch of checks like this. What you’re hoping for here is that your condition actually doesn’t pass.
You also need to force unwrap the optional value after the condition fails.
Swift gave us a way to clean this up and fix some of these flaws through Optional Binding:
1) We check for what we want
2) Do not need to force unwrap the optional. the tempX used inside the code block is unwrapped for you already.
|
1 2 3 4 5 6 7 8 |
func fooBinding(x: Int?) { if let tempX = x where x > 0 { // Do stuff with tempX tempX.description } // Value requirements not met, do something } |
This removes both of the flaws that the first function had.
The Swift Pyramid of Doom
However, it introduces a tiny problem. You might not immediately see a problem with this, but you could imagine how confusing it could become if it was nested with numerous conditions that all needed to be met before running your statements.
For example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
enum CircleAreaCalculationError: ErrorType { case RadiusNotSpecified case RadiusUnvalid } func calculateCirlceArea(radius:Double?) throws -> Double { if let radius = radius { if radius > 0 { return radius*radius*M_PI } else { throw CircleAreaCalculationError.RadiusUnvalid } } else { throw CircleAreaCalculationError.RadiusNotSpecified } } |
You’re putting your desired code within all the conditions, rather than afterward. This is a problem when you have numerous conditions that need to be met before running what you want. Conceptually, the way to fix this is to do your checks first. If any of the checks do not hold, we exit. Thus, this lets you run the code you want AFTER all the checks are satisfied. In other words, do each of your checks first, and exit if any aren’t met. This allows easy understanding of what conditions will make this function exit.
Its kinda like having a guarding your club. You only want non-smoking, long haired, and female patrons in your club. So your bouncer checks if the person is a non-smoker. Yes. Ok, next does the person have long hair? Yes. Is the person female? Yes. Okay, the patron gets to go into your club. In our case, the variable checks through and gets executed by your code below.
If any of the traits are not met, the bouncer will throw that person out. In our case, the code returns.
You want to get rid of the bad cases before they get in the door.
Solution is to use guard:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
enum CircleAreaCalculationError: ErrorType { case RadiusNotSpecified case RadiusUnvalid } func calculateCirleArea(radius:Double?) throws -> Double { guard let radius = radius else { throw CircleAreaCalculationError.RadiusNotSpecified } guard radius > 0 else { throw CircleAreaCalculationError.RadiusUnvalid } return radius*radius*M_PI } |
Solution: the guard statement
|
1 2 3 4 5 6 7 8 9 10 |
func fooGuard(x: Int?) { guard let validX = x where x > 0 else { // Value requirements not met, do something return } // Do stuff with validX validX.description } |
Using guard solves all 3 of the issues mentioned above:
-
Checking for the condition you do want.
1where x > 0
If the condition is not met, guard‘s else statement is run, which breaks out of the function. - If the condition passes, the optional variable here is automatically unwrapped for you within the scope that the guard statement was called (in this case, the fooGuard(_:) function). Thus, validX is the unwrapped variable for you to use.
You are checking for bad cases early, making your function more readable and easier to maintain.
Even if your variable is non-optional, you can also use guard
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
func fooNonOptionalGood(x: Int) { guard x > 0 else { // Value requirements not met, do something return } // Do stuff with x } func fooNonOptionalBad(x: Int) { if x <= 0 { // Value requirements not met, do something return } // Do stuff with x } |