Better Gno Error Handling

[deelawn]

Background

Panicking in Go

Why panic inside a go program? The common advice one hears is that it is best to avoid panicking when able to, as panicking may end up terminating the program if it is not recovered, and more generally results in code that is more difficult to read. Go programmers prefer to handle unexpected issues is by creating and returning a value that implements the error interface. Method or function signatures that contain the error type as one of their return values make it clear that this function may produce an error — note how this contrasts with panicking — the caller has to know if they need to expect a panic and code defensively to handle it. So why don’t gno programmers prefer to have their realm functions return errors?

Panicking in Gno

The advice in “Effective Gno” is for programmers to panic in top level realm functions rather than return an error. The main reason for this is that it may not be desirable (or impossible) to roll back realm state changes that have already been made. If a programmer does want to handle the panic, event for cross realm calls, they currently can, but this is going to change soon.

Why Am I Writing This?

With the upcoming changes that will restrict the recovery of cross realm panics, I believe that programmers that follow our “always panic” recommendation will be at a disadvantage, and maybe this advice always put that at a disadvantage. I believe there are valid use cases for why a realm author may want to continue execution on another code path after a call to another realm returns an error, or in our current case, returns a panic.

Proposal

There are a few steps that need to be taken to change how people write gno code and reduce the occurrences of panic throughout the ecosystem.

1. Changes need to be made so that error return types are converted to strings before being returned as part of the transaction result. The string value can be produced by doing evaluating the Error() method or <nil> if the error is nil. Support returning error types from a realm #416 is an old issue that proposes something similar.
2. Update our current documentation to explain why it may be better for realms to return errors rather than panic — the realms may be more attractive for other realm developers to import and use if they can choose how to resolve from the errors rather than having their transaction aborted completely.
3. Offer guidance on how to write code for realms that return errors and how to know when panic is justified.
   1. Write realm code in such a way so that all validation happens before realm values are created, deleted, or modified.
   2. If importing other realms, be wary of how they handle errors and make sure they are not returning errors and preserving data from a function call even though it returned an error.
   3. It’s still okay to panic if the code required to do validation before modifying realm values is too difficult or inefficient.
4. Leave “Effective Gno”, and other docs that frequently show examples using panic, largely as they are. Create a new page in our docs for advanced realm development that explains the pros and cons of using errors over panics, rather than definitively telling programmers that panics are always the preferred method of halting execution of a realm function.

[thinhnx-var]

I am coding realms, and I see that errors handling in gno is harder than in go. I have struggle in using errors demo package, such as letting people know what was wrong in their actions to realms clearly, and I really want the go style in these cases. Can't wait to see this PR done <3