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
Currently if an Android app tries to call a gomobile bounded method with a null parameter, that will hard panic inside the proxy classes. I assume the same holds true for iOS too.
Looking at the code, it's fairly obvious what happens: gomobile assumes that any object passed to it actually originates from inside Go, and is a proxy/wrapper object. This makes perfect sense, since it's meaningless to pass a Java object to Go directly as it doesn't know what to do with it.
Edit: Opened a CL with the proper code to support this.
That being said, I think null warrants a special behavior whereby func (r *Ref) Get() interface{} { would simply short circuit execution in such cases. I'm unsure if this is the only change needed or not (can't test it right now). But if yes, it would be an elegant way to support crossing null over as nil from Java to Go.
The rationale behind supporting this is that in Go, code often allows setting some parameters to nil to use default values (simply so that the caller doesn't have to care what those defaults are). However this "don't care" feature cannot be done, so the package needs to surface an extra constant which essentially acts as the "default/nil" placeholder.
The text was updated successfully, but these errors were encountered:
Currently the generated bindings assume that any object
passed to Go as a method argument is actually a valid one
originating from Go. The `null` object is however a corner
case to this assumption, which should be accepted for Go
pointer types, since they can cleanly convert into `nil`.
This CL modifies the generated wrapper code so any `nil`
reference is permitted for Go pointer types, which until
now produced a nil pointer dereference error.
Fixesgolang/go#20330
Change-Id: If1ab9cf9df7ac3808486d23ccf2db8d32fb89426
Reviewed-on: https://go-review.googlesource.com/43253
Reviewed-by: Elias Naur <elias.naur@gmail.com>
imWildCat
pushed a commit
to imWildCat/go-mobile
that referenced
this issue
Apr 11, 2021
Currently the generated bindings assume that any object
passed to Go as a method argument is actually a valid one
originating from Go. The `null` object is however a corner
case to this assumption, which should be accepted for Go
pointer types, since they can cleanly convert into `nil`.
This CL modifies the generated wrapper code so any `nil`
reference is permitted for Go pointer types, which until
now produced a nil pointer dereference error.
Fixesgolang/go#20330
Change-Id: If1ab9cf9df7ac3808486d23ccf2db8d32fb89426
Reviewed-on: https://go-review.googlesource.com/43253
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently if an Android app tries to call a gomobile bounded method with a
null
parameter, that will hard panic inside the proxy classes. I assume the same holds true for iOS too.Looking at the code, it's fairly obvious what happens: gomobile assumes that any object passed to it actually originates from inside Go, and is a proxy/wrapper object. This makes perfect sense, since it's meaningless to pass a Java object to Go directly as it doesn't know what to do with it.
Edit: Opened a CL with the proper code to support this.
That being said, I thinknull
warrants a special behavior wherebyfunc (r *Ref) Get() interface{} {
would simply short circuit execution in such cases. I'm unsure if this is the only change needed or not (can't test it right now). But if yes, it would be an elegant way to support crossingnull
over asnil
from Java to Go.The rationale behind supporting this is that in Go, code often allows setting some parameters to
nil
to use default values (simply so that the caller doesn't have to care what those defaults are). However this "don't care" feature cannot be done, so the package needs to surface an extra constant which essentially acts as the "default/nil" placeholder.The text was updated successfully, but these errors were encountered: