1

I have a chain of throwing calls that I need to catch, and then I need to use their result to - maybe - throw something anyway, despite all of them succeeding:

func a() throws {
    do {
        let b = try b()

        if !b.valid {
            throw SomeError()
        }
    } catch {
        throw SomeError()
    }
}

The problem with this code is:

  • I throw inside a do clause
  • This error will also be caught by catch, which I don't want

Now, one could obviously say that I should just let b outside of do:

func a1() {
    let b: B
    do {
        b = try b()
    } catch {
        throw SomeError()
    }
    
    if !b.valid {
        throw SomeError()
    }
}

But I really don't wanna to that because I have a lot of declarations:

func a2() async throws {
    let b1: B
    let b2: B
    let b3: B
    let b4: B
    let b5: B

    // ...
}

Question: is there any way to throw bypassing the catch? Maybe, I could use Swift labeled statements for this?

3
  • 1
    yes, that is possible ) Commented Aug 8, 2022 at 10:27
  • 1
    Consider to drop the do - catch block. It’s good practice to hand over thrown errors to the caller in a throwing function.
    – vadian
    Commented Aug 8, 2022 at 11:45
  • @vadian thank you for the comment - unfortunately, we would prefer to wrap all errors into a chain, a linked list where each error retains the error that provoked it, so this won't do Commented Aug 8, 2022 at 12:57

1 Answer 1

1

Labeled statements are for loops. They are not meant for normal functions. For this you could just go through all the errors you have thrown in do statement in catch block. You just need a switch statement. Like this

enum SomeError: Error {
    case someError
    case anotherError
}

func a() throws {
    do {
        let b = try b()

        if !b.isValid {
            throw SomeError.someError
        }
    } catch {
        switch error {
        case SomeError.someError:
            throw SomeError.someError
        default:
            throw SomeError.anotherError
        }
    }
}
1
  • Well, I will have to unfortunately cast the Error to SomeError, and additionally there needs to be some kind of switch-ability in the SomeError object which we need to introduce and which is not there at the moment. All of this complicates the system, but thank you for the suggestion! Commented Aug 8, 2022 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.