Closed arg0d closed 6 months ago
The worst part about this issue is that you get feedback after shipping the generated bindings to consumers :sweat_smile: Or after trying to compile them yourself.
This can be trivially fixed by the bindgen generator adding a Swift.
prefix before Error
.
This is valid Swift Code:
enum Error: Swift.Error { ... }
@arg0d you can fix a PR for this your self, just append Swift.
here: https://github.com/mozilla/uniffi-rs/blob/main/uniffi_bindgen/src/bindings/swift/templates/ErrorTemplate.swift#L86
(probably a good idea to include a "fixture" too)
(probably a good idea to include a "fixture" too)
To be clear, a new fixture may not be necessary - an addition to an existing one is generally fine - whatever works for you
@arg0d Can you try https://github.com/mozilla/uniffi-rs/commit/3d93e26ce323f19ad752fb592dc206756153a406 ? it should solve this issue :)
Looks good, thanks!
I'm trying to fix this for C#, and I'm wondering if this was a good way to fix this issue.
Shadowing "system error" type is not a good solution, it creates some really confusing code. Given the following code, it's quite natural to assume Exception
refers to System.Exception
. Reading this code, nobody would expect that Exception
might actually refer to a user defined type Exception
, rather than System.Exception
. This might introduce a really sneaky bug, where the programmer naturally expects that all exceptions will be caught, but actually only the user-defined exception would be caught, leading to uncaught exception bugs.
try {
DoSomething();
} catch (Exception e) {
..
}
I'm not sure what you mean - IIUC, that PR tries to always use the fully-qualified name when it is referring to a non-uniffi error type. I agree that someone choosing to shadow this name might be shooting themselves in the foot, but I'm not sure Uniffi needs to avoid that when the alternative is for them to just not do that?
I did some testing, and turns out I was just imagining a problem. I assumed Exception
is an implicit type in C#, but it's actually part of using System;
namespace. So if you try to using System; using uniffi.example;
where uniffi.example
contains type Exception
, C# compiler generates error: ambiguous references to 'Exception'
. I assume there is an equivalent error for Swift/Kotlin.
This might be a duplicate issue, but I didn't manage to find another issue like this.
For generated Swift code,
Error
is ambiguous with "system"Error
type.Version: v0.27.1 (I'm guessing older versions too
Error
is a very natural type name when starting a new library, IMHO the generators should be fixed to supportError
as error type name. We've already had 2 different teams working on separate projects step onto this same issue while onboarding their projects to uniffi :sweat_smile:There is a very simillar issue in C# bindings generators, https://github.com/NordSecurity/uniffi-bindgen-cs/issues/76.