Investigate Deconstructing Custom Errors

[buffalojoec]

Problem

When we write on-chain programs or utility libraries in SPL, we often define custom errors within enums, typically using thiserror, num_traits, and the various program_error traits. Note these are all wrapped into the #[spl_program_error] procedural macro one can spot in various locations throughout this repository.

Because these error implementations can convert to solana_program::program_error::ProgramError by using the ProgramError::Custom(u32) variant, we can use them in functions that return a Result<_, ProgramError>.

However, the issue is that when one of these custom errors is thrown, we only know the u32 value of that error. We can't actually call the print::<MyError>() function implemented on our custom error by the trait solana_program::program_error::PrintProgramError.

This means that if we want to configure an entrypoint, as defined below, we will encounter one of two problems if a different error is thrown besides the one we've specified in print::<_>():

• Collisions of u32 values from other error definitions, resulting in the wrong error printed!
• u32 value out of range of our specified error, resulting in Error: Unknown.

if let Err(error) = processor::process(program_id, accounts, instruction_data) {
    error.print::<MyCustomError>();
    return Err(error);
}

Solution

The correct solution is not quite yet known. It's almost certain that we'll need to adjust the way we typically manage Result return types from program processors.

One can see this idea being discussed in this comment thread.

Regardless, we should investigate how this might look, and what it would mean for both the new return types of processors and increased compute.