You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In go, calling recover() only works inside a defer to handle panics that originated within the current call frame. From the definition here:
If recover is called outside the deferred function it will not stop a panicking sequence
This is not the case in gno; calling recover() in gno will recover any panic that has happened inside or outside of the current call frame. Take this code example:
<!-- please provide a detailed description of the changes made in this
pull request. -->
## High level overview
Addresses #1656. This is meant to bring achieve parity between gno and
go's `recover` functionality. The new tests help to ensure this.
BREAKING CHANGE: this will break any realm code that has relies on the
incorrect `recover` implementation
### Changes
For the convenience of the reviewer, here are the categories of changes
that have been made:
- the `recover` function has been modified to determine whether a panic
can be recovered; this is based on both the "level" of nested defer
statements and the frame from which the panic was initiated
- `Frame`s are now stored as pointers to avoid copying frame values as
they are tracked by the `Exception`s that have been thrown
- a new `Exception` type has been defined to encapsulate both the panic
string and the frame in which it was initiated
- the machine has two new "scope" member variables for tracking levels
of `panic` and `defer`
- added safety mechanisms to retrieving frames because we may not always
want it to panic when trying to retrieve a call frame at an index that
exceeds the stack depth
- the gno standard library's `testing` package's `Recover` function no
longer works as intended; the tests have been modified to achieve the
intended behavior
- various new file tests have been added to ensure `recover` behaves as
expected in certain edge cases
<details><summary>Contributors' checklist...</summary>
- [x] Added new tests, or not needed, or not feasible
- [x] Provided an example (e.g. screenshot) to aid review or the PR is
self-explanatory
- [x] Updated the official documentation or not needed
- [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message
was included in the description
- [x] Added references to related issues and PRs
- [x] Provided any useful hints for running manual tests
- [ ] Added new benchmarks to [generated
graphs](https://gnoland.github.io/benchmarks), if any. More info
[here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md).
</details>
In go, calling
recover()
only works inside a defer to handle panics that originated within the current call frame. From the definition here:This is not the case in gno; calling
recover()
in gno will recover any panic that has happened inside or outside of the current call frame. Take this code example:The output should be a panic with the message
do something panic
. Instead we get the messagedo something else panic
.I think perhaps the path to solving this is to save panics in the last call frame's struct rather than in the machine's struct.
Note that fixing this will render the
testing
standard library'sRecover
method useless.The text was updated successfully, but these errors were encountered: