Error Handling in Composable Applications

Related to Application read & write interfaces, @paulcadman and I started to think about error handling, which is important, especially in the context of composable applications.

Related to the ApplicationWriteInterface:

  • Users can provide wrong inputs
    • 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.

@degregat @mariari @jan

2 Likes

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?

1 Like

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.

2 Likes

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).

2 Likes