Error dealing with fundamentals in Swift

The way in which of dealing with errors modified quite a bit because the first model of Swift. The primary massive milestone occurred in Swift 2, the place Apple utterly revamped error administration. These days you should use the do, attempt, catch, throw, throws, rethrows key phrases as an alternative of coping with nasty NSError pointers, so this was a warmly welcomed addition for the language. Now in Swift 5 we take one other large leap ahead by introducing the End result kind as a built-in generic. First, let me present you all the very best practices of error dealing with within the Swift programming language, subsequent I am going to present you some cool stuff through the use of outcomes to cope with errors. 🚧

Optionals as error indicators

For easy situations you may at all times use elective values, to point that one thing dangerous 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)

When you do not actually care in regards to the underlying kind of the error, this strategy is ok, however typically issues can get extra difficult, so that you would possibly want some particulars about the issue. Anyway, you may at all times cease the execution by calling the fatalError technique, however in the event you accomplish that, effectively… your app will crash. 💥

There are additionally a pair different methods of cease execution course of, however this might 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 through the use of the Error protocol

You’ll be able to outline your personal error sorts by merely confirming to the built-in Error protocol. Often most builders use an enum with a view to outline totally different causes. You can even have a customized error message in the event 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 lift an error of your kind, however in the event you accomplish that in a perform, you need to mark that perform as a throwing perform with the throws key phrases. 🤮

enum DivisionError: Error {
    case zeroDivisor
}

extension DivisionError: LocalizedError {
    public var errorDescription: String? {
        swap 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 might be a number of forms of errors associated to permission or file existence, and so on.

Rethrowing Features and Strategies A perform or technique will be declared with the rethrows key phrase to point that it throws an error provided that certainly one of it’s perform parameters throws an error. These capabilities and strategies are generally known as rethrowing capabilities and rethrowing strategies. Rethrowing capabilities and strategies should have at the very least one throwing perform parameter.

Okay, so a throwing perform can emit totally different error sorts, additionally it could possibly 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 may be undoubtedly room for attempting out issues! Unhealthy joke, proper? 😅

do {
    let quantity = attempt 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 may see the syntax is fairly easy, you have got a do block, the place you may attempt to execute your throwing capabilities, if one thing goes mistaken, you may deal with the errors in several catch blocks. By default an error property is obtainable inside each catch block, so you do not have to outline one your self by hand. You’ll be able to nonetheless have catch blocks for particular error sorts by casting them utilizing the let error as MyType sytnax proper subsequent to the catch key phrase. So at all times attempt first, do not simply do! 🤪

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

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

Generally in the event you do not actually care in regards to the underlying error, you may merely convert your throwing perform end result into an elective through the use of attempt?. With this strategy you may get a 0 end result if one thing dangerous occurs, in any other case you may get again your common worth as it’s anticipated. Right here is the instance from above through the use of attempt?:

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

One other method is to stop error propagation through the use of attempt!, however you need to be extraordinarily cautious with this strategy, as a result of if the execution of the “tried perform” fails, your utility will merely crash. So use provided that you are completely positive that the perform will not throw an error. ⚠️

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

There are just a few locations the place it is accepted to make use of pressure attempt, however in many of the circumstances it’s best to go on an alternate path with correct error handlers.

Swift errors are usually not exceptions

The Swift compiler at all times requires you to catch all thrown errors, so a scenario of unhandled error won’t ever happen. I am not speaking about empty catch blocks, however unhandled throwing capabilities, so you may’t attempt 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 end result kind

Swift 5 introduces a long-awaited generic end result kind. Which means error dealing with will be much more easy, with out including your personal end result implementation. Let me present you our earlier divide perform through the use of 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 end result = divide(10, by: 2)
swap end result {
case .success(let quantity):
    print(quantity)
case .failure(let error):
    print(error.localizedDescription)
}

The end result 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 capabilities can throw any sort of errors, however right here you may see from the implementation {that a} DivisionError is coming again if one thing dangerous occurs. One other profit is that you should use exhaustive swap blocks to “iterate by way of” all of the attainable error circumstances, even and not using a default case. So the compiler can maintain you secure, e.g. if you will introduce a brand new error kind inside your enum declaration.

So through the use of the End result kind it is clear that we’re getting again both end result information or a strongly typed error. It isn’t attainable to get each or neither of them, however is that this higher than utilizing throwing capabilities? Effectively, 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 = attempt calculate()
        print(quantity)
    }
    catch {
        print(error.localizedDescription)
    }
}

Oh, my expensive… an interior closure! A completion handler that accepts a throwing perform, so we are able to propagate the error thrown to the outer handler? I am out! 🤬

Another choice is that we get rid of the throwing error utterly and use an elective 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) { end result in
    guard let quantity = end result 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 effectively. You must observe that each parameters have to 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) { end result, error in
    guard error == nil else {
        fatalError(error!.localizedDescription)
    }
    guard let quantity = end result else {
        fatalError("Empty end result.")
    }
    print(quantity)
}

Lastly let’s introduce end result, so we are able to get rid of 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) { end result in
    swap end result {
    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 through the use of the End result kind. When you take into account that many of the apps are doing a little sort of networking, and the result’s often a JSON response, there you have already got to work with optionals (response, information, error) plus you have got a throwing JSONDecoder technique… cannot wait the brand new APIs! ❤️

Working with the End result kind in Swift 5

We already know that the end result kind is principally an enum with a generic .succes(T) and a .failure(Error) circumstances, however there may be extra that I might like to point out you right here. For instance you may create a end result kind with a throwing perform like this:

let end result = End result {
    return attempt divide(10, by: 2)
}

Additionally it is attainable to transform again the end result worth by invoking the get perform.

do {
    let quantity = attempt end result.get()
    print(quantity)
}
catch {
    print(error.localizedDescription)
}

Additionally there are map, flatMap for remodeling success values plus you can too use the mapError or flatMapError strategies if you would like to remodel failures. 😎

let end result = divide(10, by: 2) 


let mapSuccess = end result.map { divide($0, by: 2) } 


let flatMapSuccess = end result.flatMap { divide($0, by: 2) } 
let mapFailure = end result.mapError { 
    NSError(area: $0.localizedDescription, code: 0, userInfo: nil)
}

let flatMapFailure = end result.flatMapError { 
    .failure(NSError(area: $0.localizedDescription, code: 0, userInfo: nil)) 
}

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