Replies: 5 comments 5 replies
-
I agree with this effort. @jimscarver and I have been haggling about these sorts of conventions for a while now. An alternative inspired by C++ exceptions in regular C: This allows us to add to the exception-map as we "unwind the stack"
|
Beta Was this translation helpful? Give feedback.
-
@Bill-Keuntje @jimscarver Why does the checkBalance call return a list of 2 strings and the balance? Is that required by JS? It is causing me a lot of trouble in python, I can't figure out how to access each field of the return value |
Beta Was this translation helpful? Give feedback.
-
@jimscarver (true, data) or (false, {error info}) Do we know that there are no display problems in the browser for these tuples? |
Beta Was this translation helpful? Give feedback.
-
I believe we have agreed that since strict structure layouts in Par types that we can create the strict return values in the API layer above rhoang. If I am correct we can close this issue |
Beta Was this translation helpful? Give feedback.
-
Yes
On July 10, 2021 6:56:58 PM EDT, Bill-Kunj ***@***.***> wrote:
***@***.*** @jimscarver
…I agree that we can standardize on ```(T, value) (F, {error-map})```
Are we good and can close this down?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#125 (reply in thread)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
Beta Was this translation helpful? Give feedback.
-
Looking at the pyrgov possibilities I see one area that needs improvement
The rholang code is not consistent on return values
We need a defined standard for return values
For example if an unrecoverable exception happens how is that communicated?
Since we have variable return structures available to us (in both python as well as JS and most API languages anyone wants to use) I would like to propose something like this:
[Status, "meaning", {return}]
Status is a boolean that signals that the code executed without exceptions
"meaning" is a human readable meaning of the status
return is an optional element that contains any application data that was returned
Some examples:
[True, "OK"] - the code executed properly no return value
[False, "network not reachable"]
[True, "OK", ["#define", "Balance", 10000000]]
etc
Upon looking at it closer, the return is what the rholang returns, the Status/meaning really comes from the API wrapper.
Does JS have the ability to catch raised exceptions for when the rnode is unreachable or other catastrophic failure?
If not, then maybe this is just useful for the python interface
And a secondary question: why does checkBalance return a #define?
Beta Was this translation helpful? Give feedback.
All reactions