FFIError carrying string message

[cretz]

Looking to see if there's a pattern for a FFIError that carries a message. FFIError requires those consts which means I can't even find a way to instantiate a compile-time struct w/ AsciiPointer (or FFIOption or similar). Suggestions?

[ralfbiedert]

I don't quite get the 2nd part what you are saying, but the trait FFIError is purely to signal to Interoptopus which of your error variants it should pick when it detects a null or panic!().

"Carrying a message" needs probably more discussion, like what's the format of that message (a string?) and who should receive it, when and how will it pass the FFI boundary?

[cretz]

like what's the format of that message (a string?) and who should receive it, when and how will it pass the FFI boundary?

Yes, sorry, a string and I would want it just like any other result, the lang layer just throws it instead. For service errors, the FFIError is not very dynamically usable as is due to const and enum requirements.

For example, you can't have:

#[ffi_type(patterns(ffi_error))]
#[repr(C)]
pub struct CoreError<'a> {
    pub message: AsciiPointer<'a>,
}

impl<'a> FFIError for CoreError<'a> {
    const SUCCESS: Self = CoreError { message: <what compile-time can go here> };
    const NULL: Self = CoreError { message: <what compile-time can go here> };
    const PANIC: Self = CoreError { message: <what compile-time can go here> };
}

There are no "FFI safe" + "const" ways to pass a message that I can find to satisfy FFIError needs. I tried #[ffi_type(opaque, patterns(ffi_error))] too but it fails at gen time expecting an enum:

Constructor must return a ffi_error type pattern.

I can understand if not supported, just want to know what the suggested approach here is for #[ffi_service_method] that return errors that do not map to repr(C) enums. Is it expected to Result<SuccessOrError, Error>?

[ralfbiedert]

Ah, yes, this is not supported:

impl<'a> FFIError for CoreError<'a> {
    const SUCCESS: Self = CoreError { message: <what compile-time can go here> };
    const NULL: Self = CoreError { message: <what compile-time can go here> };
    const PANIC: Self = CoreError { message: <what compile-time can go here> };
}

The main reason is FFIError is part of an automated machine which must decide at runtime whether a call succeeded or not, and be able to do that easily in all backend languages.

Right now only integers (enums) support that. In your case you'd now have to, say, compare the internals of CoreError in C# and inspect if it contains a certain magic AsciiPointer (how would it know in C# which pointer is the good one?), and only then you'd know if you succeeded or panicked.

So FFIError is not the right construct for this as of now.

want to know what the suggested approach here is for #[ffi_service_method] that return errors that do not map to repr(C) enums

The way forward would be something like #40 (and the related stub #28), but that needs investigation and work.

In the meantime, the only hack you could do is to give it an on_panic = undefined_behavior attribute which allows you to return whatever you want, and write a check for that manually in your backend code.

[cretz]

Thanks! I think I'll have a Result<MySuccessOrError, Error> result then and just write all of my Rust code to return Ok with my errors embedded.