hyperledger
FFI error handling
implement better error handling over FFI as is described here. Currently, only error codes are transferred over the FFI boundary
resuming panics should also be considered: https://doc.rust-lang.org/std/panic/fn.resume_unwind.html
Moved back to to do until #2314 is merged, because it heavily affects this task.
@ales-tsurko , #2314 was merged, do you plan to work on this?
Hi! I'm on vacation until August, 29. So no at least until this date
When an extern function fails an error code FfiReturn is returned. The user can then query iroha_ffi to get more details on the error via another extern function named take_error/take_last_error/last_error or similar. IMO this should best be done via ffi_export annotation to expose the function for retrieving errors as follows:
#[ffi_export]
fn take_last_error() -> Option<Box<Error>> {
// ...
}
there should never be any need to write code for FFI serialization/deserialization.
It should be made clear that this approach is
- Not exactly standard Rust.
- Not particularly ergonomic, since the user has to remember to check for the error, it would require considerably code being added to the FFI user which defeats the purpose of dynamic linkage.
It should be noted that the user of the FFI is only expected to handle a limited number of errors, the rest can just be logged for debugging purposes.
I see no reason why the few errors that can be handled couldn't be passed like any other FFI struct, and in some cases just converted to a string with the impl Debug.
1. Not exactly standard Rust. 2. Not particularly ergonomic, since the user has to remember to check for the error, it would require considerably code being added to the FFI user which defeats the purpose of dynamic linkage.
the idea was to autogenerate the error handling code on the smart contract side and hide the complexity behind a know API so the user wouldn't bear the burden. To the user this would all look like a standard Rust code. However, in the background, the shim code would incur another FFI call for every error returned which IMHO shouldn't be noticeable unless we were to fetishize error handling mechanism as a control flow mechanism, which we don't.
I see no reason why the few errors that can be handled couldn't be passed like any other FFI struct, and in some cases just converted to a string with the
impl Debug.
This is a valid approach. I didn't prefer it done this way, but I don't oppose it strongly either. Bear in mind that extern functions are optimization barriers. The approach suggested by me would favorize the happy path, serializing results like "any other struct" would make a compromise on the happy path to support returning errors