use the consequence kind to deal with errors in Swift 5?

Error dealing with fundamentals in Swift

The way in which of dealing with errors modified quite a bit for the reason that first model of Swift. The primary huge milestone occurred in Swift 2, the place Apple fully revamped error administration. These days you should utilize the do, strive, catch, throw, throws, rethrows key phrases as a substitute of coping with nasty NSError pointers, so this was a warmly welcomed addition for the language. Now in Swift 5 we take one other big leap ahead by introducing the End result kind as a built-in generic. First, let me present you all the perfect practices of error dealing with within the Swift programming lanugage, subsequent I am going to present you some cool stuff by utilizing outcomes to cope with errors. 🚧

Optionals as error indicators

For easy situations you possibly can at all times use optionally available values, to point that one thing unhealthy occurred. Additionally the guard assertion is extraordinarily useful for conditions like this.

let zeroValue = Int("0")! 
let nilValue = Int("not a quantity") 

guard let quantity = Int("6") else {
    fatalError("Ooops... this could at all times work, so we crash.")
}
print(quantity)

In the event you do not actually care concerning the underlying kind of the error, this method is ok, however typically issues can get extra sophisticated, so that you may want some particulars about the issue. Anyway, you possibly can at all times cease the execution by calling the fatalError technique, however in case you accomplish that, properly… your app will crash. 💥

There are additionally a pair different methods of cease execution course of, however this may very well be a subject of a standalone put up, so right here is only a fast cheat sheet of obtainable strategies:

precondition(false, "ouch")
preconditionFailure("ouch")
assert(false, "ouch")
assertionFailure("ouch")
fatalError("ouch")
exit(-1)

The important thing distinction between precondition and assertion is that assert will work solely in debug builds, however precondition is evaluated at all times (even in launch builds). Each strategies will set off a deadly error if the situation fails aka. is fake. ⚠️

Throwing errors by utilizing the Error protocol

You’ll be able to outline your individual error varieties by merely confirming to the built-in Error protocol. Often most builders use an enum with a view to outline completely different causes. You may also have a customized error message in case you conform to the LocalizedError protocol. Now you are able to throw customized errors, simply use the throw key phrase if you would like to boost an error of your kind, however in case you accomplish that in a perform, you must mark that perform as a throwing perform with the throws key phrases. 🤮

enum DivisionError: Error {
    case zeroDivisor
}

extension DivisionError: LocalizedError {
    public var errorDescription: String? {
        change self {
        case .zeroDivisor:
            return "Division by zero is kind of problematic. " +
                   "(https://en.wikipedia.org/wiki/Division_by_zero)"
        }
    }
}

func divide(_ x: Int, by y: Int) throws -> Int {
    guard y != 0 else {
        throw DivisionError.zeroDivisor
    }
    return x / y
}

Nice, so the divide perform above can generate a customized error message. If the divisor is zero it will throw the zeroDivision error case. Now think about the next state of affairs: you are attempting to learn the contents of a file from the disk. There may very well be a number of varieties of errors associated to permission or file existence, and many others.

Rethrowing Capabilities and Strategies A perform or technique may be declared with the rethrows key phrase to point that it throws an error provided that considered one of it’s perform parameters throws an error. These features and strategies are generally known as rethrowing features and rethrowing strategies. Rethrowing features and strategies will need to have a minimum of one throwing perform parameter.

Okay, so a throwing perform can emit completely different error varieties, additionally it will probably propagate all of the parameter errors, however how can we deal with (or ought to I say: catch) these errors?

The do-try-catch syntax

You simply merely need to attempt to execute do a throwing perform. So do not belief the grasp, there’s positively room for attempting out issues! Unhealthy joke, proper? 😅

do {
    let quantity = strive divide(10, by: 0)
    print(quantity)
}
catch let error as DivisionError {
    print("Division error handler block")
    print(error.localizedDescription)
}
catch {
    print("Generic error handler block")
    print(error.localizedDescription)
}

As you possibly can see the syntax is fairly easy, you’ve gotten a do block, the place you possibly can strive to execute your throwing features, if one thing goes mistaken, you possibly can deal with the errors in several catch blocks. By default an error property is offered inside each catch block, so you do not have to outline one your self by hand. You’ll be able to nevertheless have catch blocks for particular error varieties by casting them utilizing the let error as MyType sytnax proper subsequent to the catch key phrase. So at all times strive first, do not simply do! 🤪

Variations between strive, strive? and take a look at!

As we have seen earlier than you possibly can merely strive to name a perform that throws an error inside a do-catch block. If the perform triggers some type of error, you possibly can put your error dealing with logic contained in the catch block. That is quite simple & easy.

Generally in case you do not actually care concerning the underlying error, you possibly can merely convert your throwing perform consequence into an optionally available by utilizing strive?. With this method you may get a 0 consequence if one thing unhealthy occurs, in any other case you may get again your common worth as it’s anticipated. Right here is the instance from above by utilizing strive?:

guard let quantity = strive? divide(10, by: 2) else {
    fatalError("This could work!")
}
print(quantity) 

One other method is to forestall error propagation by utilizing strive!, however you must be extraordinarily cautious with this method, as a result of if the execution of the “tried perform” fails, your software will merely crash. So use provided that you are completely certain that the perform will not throw an error. ⚠️

let quantity = strive! divide(10, by: 2) 
print(quantity)

There are a couple of locations the place it is accepted to make use of drive strive, however in many of the instances it is best to go on an alternate path with correct error handlers.

In Swift 5 nested optionally available strive? values are going to be flattened to a single optionally available worth. SE-0230 is an already carried out proposal that may break some current Swift code. Paul Hundson has a fast article about this conduct.

Swift errors are usually not exceptions

The Swift compiler at all times requires you to catch all thrown errors, so a state of affairs of unhandled error won’t ever happen. I am not speaking about empty catch blocks, however unhandled throwing features, so you possibly can’t strive with out the do-catch companions. That is one key distinction when evaluating to exceptions. Additionally when an error is raised, the execution will simply exit the present scope. Exceptions will often unwind the stack, that may result in reminiscence leaks, however that is not the case with Swift errors. 👍

Introducing the consequence kind

Swift 5 introduces a long-awaited generic consequence kind. Which means error dealing with may be much more easy, with out including your individual consequence implementation. Let me present you our earlier divide perform by utilizing End result.

func divide(_ x: Int, by y: Int) -> End result<Int, DivisionError> {
    guard y != 0 else {
        return .failure(.zeroDivisor)
    }
    return .success(x / y)
}

let consequence = divide(10, by: 2)
change consequence {
case .success(let quantity):
    print(quantity)
case .failure(let error):
    print(error.localizedDescription)
}

The consequence kind in Swift is principally a generic enum with a .success and a .failure case. You’ll be able to move a generic worth in case your name succeeds or an Error if it fails.

One main benefit right here is that the error given again by result’s kind secure. Throwing features can throw any type of errors, however right here you possibly can see from the implementation {that a} DivisionError is coming again if one thing unhealthy occurs. One other profit is that you should utilize exhaustive change blocks to “iterate by” all of the attainable error instances, even and not using a default case. So the compiler can maintain you secure, eg. if you will introduce a brand new error kind inside your enum declaration.

So by utilizing the End result kind it is clear that we’re getting again both consequence knowledge or a strongly typed error. It is not attainable to get each or neither of them, however is that this higher than utilizing throwing features? Properly, let’s get asynchrounous!

func divide(_ x: Int, by y: Int, completion: ((() throws -> Int) -> Void)) {
    guard y != 0 else {
        completion { throw DivisionError.zeroDivisor }
        return
    }
    completion { return x / y }
}

divide(10, by: 0) { calculate in
    do {
        let quantity = strive calculate()
        print(quantity)
    }
    catch {
        print(error.localizedDescription)
    }
}

Oh, my pricey… an internal closure! A completion handler that accepts a throwing perform, so we will propagate the error thrown to the outer hander? I am out! 🤬

An alternative choice is that we remove the throwing error fully and use an optionally available because of this, however on this case we’re again to sq. one. No underlying error kind.

func divide(_ x: Int, by y: Int, completion: (Int?) -> Void) {
    guard y != 0 else {
        return completion(nil)
    }
    completion(x / y)
}

divide(10, by: 0) { consequence in
    guard let quantity = consequence else {
        fatalError("nil")
    }
    print(quantity)
}

Lastly we’re getting someplace right here, however this time let’s add our error as a closure parameter as properly. It’s best to notice that each parameters must be optionals.

func divide(_ x: Int, by y: Int, completion: (Int?, Error?) -> Void) {
    guard y != 0 else {
        return completion(nil, DivisionError.zeroDivisor)
    }
    completion(x / y, nil)
}

divide(10, by: 0) { consequence, error in
    guard error == nil else {
        fatalError(error!.localizedDescription)
    }
    guard let quantity = consequence else {
        fatalError("Empty consequence.")
    }
    print(quantity)
}

Lastly let’s introduce consequence, so we will remove optionals from our earlier code.

func divide(_ x: Int, by y: Int, completion: (End result<Int, DivisionError>) -> Void) {
    guard y != 0 else {
        return completion(.failure(.zeroDivisor))
    }
    completion(.success(x / y))
}

divide(10, by: 0) { consequence in
    change consequence {
    case .success(let quantity):
        print(quantity)
    case .failure(let error):
        print(error.localizedDescription)
    }
}

See? Strongly typed errors, with out optionals. Dealing with errors in asynchronous perform is means higher by utilizing the End result kind. In the event you think about that many of the apps are performing some type of networking, and the result’s often a JSON response, there you have already got to work with optionals (response, knowledge, error) plus you’ve gotten a throwing JSONDecoder technique… cannot wait the brand new APIs! ❤️

Working with the End result kind in Swift 5

We already know that the consequence kind is principally an enum with a generic .succes(T) and a .failure(Error) instances, however there’s extra that I might like to point out you right here. For instance you possibly can create a consequence kind with a throwing perform like this:

let consequence = End result {
    return strive divide(10, by: 2)
}

It’s also attainable to transform again the consequence worth by invoking the get perform.

do {
    let quantity = strive consequence.get()
    print(quantity)
}
catch {
    print(error.localizedDescription)
}

Additionally there are map, flatMap for remodeling success values plus it’s also possible to use the mapError or flatMapError strategies if you would like to remodel failures. 😎

let consequence = divide(10, by: 2) 
let mapSuccess = consequence.map { divide($0, by: 2) } 
let flatMapSuccess = consequence.flatMap { divide($0, by: 2) } 
let mapFailure = consequence.mapError { NSError(area: $0.localizedDescription, code: 0, userInfo: nil) }
let flatMapFailure = consequence.flatMapError { .failure(NSError(area: $0.localizedDescription, code: 0, userInfo: nil)) }

That is it concerning the End result kind in Swift 5. As you possibly can see it is extraordinarily highly effective to have a generic implementation constructed straight into the language. Now that we have now consequence, I simply want for larger kinded varieties or an async / await implementation. 👍