You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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 variousprogram_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 theProgramError::Custom(u32)
variant, we can use them in functions that return aResult<_, 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 theprint::<MyError>()
function implemented on our custom error by the traitsolana_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::<_>()
:u32
values from other error definitions, resulting in the wrong error printed!u32
value out of range of our specified error, resulting inError: Unknown
.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.
The text was updated successfully, but these errors were encountered: