External Errorsupport

[stan-irl]

I have a common error that I want to return from a few APIs called ApiError. I have defined this in my error crate:

[Error]
enum ApiError {
    "Unknown",
    "Internal",
    ...
};

When I include this error as an external in another crate, the generated kotlin code tries to import ApiError, but when the kotlin class is created it has been renamed to ApiException so my kotlin package doesnt compile.

It looks like this is intended behaviour that was introduced in 0.13.0

The docs mention that errors should work as externals here so I'm not really sure what is the best way to deal with this.

For now i'm working around this by just naming my enum ApiErr

┆Issue is synchronized with this Jira Task
┆Issue Number: UNIFFI-286

[mhammond]

ExternalTypes are proving problematic in some cases, because we don't know what they are. A solution to this specific problem is probably to add a new variant here so that the bindings generator knows the type is an error. Longer term I wonder if leaning into "library mode" is the way to go so that we can learn about the actual type of all "external" types.

[bendk]

I think #1600 maybe addresses part of the issue here, but after that I see this error:

thread 'main' panicked at 'unsupported type for error: External { name: "UniffiOneError", crate_name: "uniffi_one", kind: DataClass }', uniffi_bindgen/src/bindings/kotlin/gen_kotlin/mod.rs:238:18

Once that's merged I can take a look and try to fix this one. I don't think it's too hard.

Did we ever support external errors? I don't see any code in fixtures/ext-types that tests that

[mhammond]

Did we ever support external errors?

I don't think so, but more by omission than intent.

[threema-lenny]

I think #1600 maybe addresses part of the issue here, but after that I see this error:

thread 'main' panicked at 'unsupported type for error: External { name: "UniffiOneError", crate_name: "uniffi_one", kind: DataClass }', uniffi_bindgen/src/bindings/kotlin/gen_kotlin/mod.rs:238:18

Once that's merged I can take a look and try to fix this one. I don't think it's too hard.

Did we ever support external errors? I don't see any code in fixtures/ext-types that tests that

I'm now running into this, too. What would need to be done to address this?

[mhammond]

I'm now running into this, too. What would need to be done to address this?

I doubt this will be a trivial change. Off the top of my head, I suspect ErrorMetadata would need to grow a variant for the external type, but I suspect you'd then hit a blocker which is that you will struggle to work out what the type actually is - ie, you will probably be unable to differentiate an enum with the error attribute from a regular enum from a record.

[threema-lenny]

Thanks, that does sound rather involved, yeah. It seems to be a common thing when using a multi-crate workspace. Is there a way to avoid this issue besides moving everything into a single crate (which, at least for us, would be a legitimate last resort option)?

[mhammond]

I'm afraid I can't think of another work around. While I said the change might not be trivial, I also don't think it would be particularly complicated, and I'd be happy to help with guidance.

[mhammond]

All done other than #2392 and #2393