Unauthorized resources (e.g., trying to send Kudos that you don’t own).
Quantities that exceed balances (e.g., trying to send more Kudos than you own).
Resources that are incompatible with each other (e.g., trying to merge 4 Apple resource with 3 Orange resources to obtain a 7 Apple resource)
The resource logic could have time-constraints so that resources could be expired
…
Related to both, the ApplicationRead- and ApplicationWriteInterface:
Storage service providers might have stopped storing the resource or parts of it (i.e., the r.logic or r.data)
Resource data or extra data can contain unexpected values
Not knowing failure causes would result in bad a UX. Accordingly, interfaces should conduct checks and return meaningful error messages that can bubble up (which is very important for composed applications).
For errors related to service commitments, the Anoma node should think about error handling for users as well.
From the point of view of Juvix, do we need to handle these errors in any more sophisticated way than just interrupting execution with an appropriate error message?
I guess the point about compositionality here is that this is not enough? You want to be able to resume execution after an error occurred?
Good question! Let’s say there is a learning platform app where people mentor each other. Users can write Multichat messages and send Kudos to each other through a frontend.
This frontend would call transaction functions on the learning function app that in turn call transaction functions from Multichat and Kudos.
The question is now what needs to happen if an error occurs in Multichat (maybe the user has been blocked) or in Kudos (maybe the balance is not sufficient/up-to-date).
As a user, I want to get detailed information to understand what the problem is.
do we need to handle these errors in any more sophisticated way than just interrupting execution with an appropriate error message?
Possibly yes.
E.g., if multiple Kudos or Multichat calls happen within one learning app transaction function call, we might want to give additional details, where it went wrong exactly.
Maybe the app wants to also try/catch things (although his doesn’t sound like a good design to me).
I think these would be more sophisticated cases that seem realistic, but I would like to hear more opinions on this.
Great questions here. I think one affordance that we’ll definitely want is the ability for transaction functions to output logs (or to output a trace from which can be computed logs) when executing, and for resource logics to similarly be able to return some kind of meaningful error message (or to output a trace from which can be computed a meaningful error message). The types of these error messages can then become part of the type of the application, and composition of applications will entail composition of potential errors (and maybe some application compositions will want to provide further abstractions over lower-level error messages).
Personally, I would start there, and then we can figure out what kinds of “smart” retry logic might be built into certain applications (but probably on the frontend side, not the application definition itself).
“default error display” behavior under composition will probably depend on how the applications are composed.
E.g. in the learning app, if I have a button to send a kudo to a user in some multichat room, it would make sense to display a notification that a kudo send failed in the room or next to the user I tried to send to, but if my kudo app could log all kudo relevant errors, independent of the initial calls that triggered them, this would be useful too.