Skip to content

Conversation

@cristianFleita
Copy link
Contributor

Description

This PR enhances exception handling in the WebGL implementation of the executeRaw function and updates the AccountExecuteRawHelper class to improve callback handling.

Changes Made

  • WebGL JavaScript Side: Wrapped the account pointer and buffer allocation within a try-catch-finally block.
  • AccountExecuteRawHelper Class: Updated the callback method to handle JSON-serialized messages indicating success or failure.

}
catch (Exception e)
{
Debug.LogError($"Error in ExecuteRaw: {e.Message}");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like if we end up wrapping the error by a try on the JS side and returning a Result then we shouldn't even throw. Since we wouldn't necessarily want to stop the game loop just because a transaction failed. We could maybe make ExecuteRaw return if the transaction failed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yes, you got a point.

I could wrap the result of the execution on this class:

public class Result<T>
{
        public bool IsSuccess { get; }
        public T Value { get; }
        public string Error { get; }

        private Result(T value, string error, bool isSuccess)
        {
            Value = value;
            Error = error;
            IsSuccess = isSuccess;
        }

        public static Result<T> Success(T value) => new Result<T>(value, null, true);
        public static Result<T> Failure(string error) => new Result<T>(default(T), error, false);
 }

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants