Cadence Error Recovery

[m-Peter]

Cadence Error Recovery

Grant category

• [x] Developer tools / services
• [x] Open source maintenance

Description

Cadence is the native programming language used for developing smart contracts / scripts / transactions that run on the Flow Blockchain. It comes with some handy built-in functions in its standard library, such as the panic function.

Problem statement

While working on improving the Cadence testing framework, we realized the need for a matcher that can allow / expect errors from Cadence code. This was not part of the grant's deliverables, however we proceeded with an implementation which has already been approved & merged. It then occurred to us, that this functionality is also missing from the Cadence standard library.

Proposed solution

Introduce a new standard library function (recoverPanic), which will enable error handling in Cadence. One functional prototype can be seen below:

pub struct Foo {
    priv let answer: Int

    init(answer: Int) {
        self.answer = answer
    }

    pub fun correctAnswer(_ input: Int): Bool {
        if self.answer != input {
            panic("wrong answer!")
        }
        return true
    }
}

pub fun main(input: Int): String {
    let foo: Foo = Foo(answer: 42)
    var isCorrect: Bool = false

    recoverPanic(fun(): Void {
        isCorrect = foo.correctAnswer(input)
    })

    if isCorrect {
        return "Yaay! ".concat(input.toString()).concat(" is the correct answer!")
    } else {
        return input.toString().concat(" is not the correct answer..")
    }
}

And its usage:

➜  flow-code-coverage git:(main) ✗ ~/Dev/forks/flow-cli/cmd/flow/flow-x86_64-linux- scripts execute recover_panic_script.cdc 42

Result: "Yaay! 42 is the correct answer!"

➜  flow-code-coverage git:(main) ✗ ~/Dev/forks/flow-cli/cmd/flow/flow-x86_64-linux- scripts execute recover_panic_script.cdc 43

Result: "43 is not the correct answer.."

The above functionality is inspired from the RecoverErrors method defined on Cadence Interpreter, and can only be implemented natively.

Impact

Error handling / recovery is a must-have for any programming language. Developers will be able to recover from panic calls that occur in other smart contracts, which in turn will result in better composability.

Milestones and funding

Milestone	Deliverables	Timeline	Risks	USD proposal
1 - Implementation	Introduce the recoverPanic function along with tests/documentation/examples	~ 2 weeks	N/A	6,000

This is a follow-up to the addition of Test.expectFailure which has already been completed.

Team

Name	Role	Bio	Contact
Ardit Marku	Back-end Engineer	A seasoned back-end engineer with a focus on problem solving and designing robust software systems. Over 8 years of experience building high-traffic search engines, marketplaces, exchanges and in-house analytics solutions. Led cross-functional teams to deliver both web and mobile apps, participating in all steps of the software development lifecycle. Open source lover and advocate.	markoupetr@gmail.com m_peter

[turbolent]

Hi Build Squad team!

It is great to see interest in this area! The Cadence team has been thinking and investigating such a language feature for a while. Recently, investigations have become high priority in the hopes that it would allow users to force delete resources.

The feature is very complex and uncertain, so it is unlikely that a grant for it is proposed or accepted. For example, such a feature has wide-ranging impact on the type system (e.g. resource typing) and the storage layer (support for snapshots and rollback). We are keen to work with the community and welcome collaboration. Currently we are discussing possibilities and we are planning to have breakout sessions for this topic soon.

[m-Peter]

@turbolent Thanks for your answer :bow: It was rather naive of me, to think that such a pattern was left out without a reason :see_no_evil: But anyway I took a shot at it, as we're transitioning from only makings tools around Cadence, to also adding functionality to the language itself. The subtleties that you mentioned were rather difficult for us to grasp beforehand.

[turbolent]

@m-Peter Not at all! It's great to see there is both interest in the feature and making it a reality 🙌