Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/mobile: NSError, is there a way to pass code? #14510

Closed
arvenil opened this issue Feb 25, 2016 · 4 comments
Closed

x/mobile: NSError, is there a way to pass code? #14510

arvenil opened this issue Feb 25, 2016 · 4 comments

Comments

@arvenil
Copy link

arvenil commented Feb 25, 2016

Some function calls can return errors and for ios they are converted to NSError. I wonder if there is a way to send more information on the error than just string? Like error code? [NSError errorWithDomain:errDomain code:1 userInfo:details] is there a way to have different error code than 1?
Or any other way to add some additional info or the option I have is to use error text as "key" for matching errors between ios and gomobile library?

@hyangah
Copy link
Contributor

hyangah commented Feb 29, 2016

Please use golang-nuts@ for questions or feature requests in the future.

The only assumption we can make on Go's error type is it implements the error interface's Error which returns a string. We may consider supporting flexible error type bindings but currently, the only way I can think of is either to use the error text as the key for matching errors, or design your API to return a structured error information based on your application's need instead. For example, let it return a struct that returns a integer code and the error details etc in case of error, or nil in case of success.

@hyangah hyangah closed this as completed Feb 29, 2016
@arvenil
Copy link
Author

arvenil commented Mar 1, 2016

You can't use structured error information e.g. struct that returns a integer code and the error details etc in case of error, or nil in case of success because gomobile strictly forbids using anything else than error interface as second parameter.

gomobile: functions and methods must return either zero or one values, and optionally an error

What could easily work is to allow some kind of special error struct e.g. type GomobileError struct { Code int } the same way as for example we have https://golang.org/pkg/net/#DNSConfigError
However, making a generic like above doesn't work in this case IMO as android exceptions doesn't have error codes.

So maybe back to the root of the problem. Right now it's impossible to match errors between golang code and ios/android in some systematic way. In golang for example we can check if package exported error pointer is the same as returned error or by using type assertion. When it comes to matching errors between golang and ios/android we can only base on error message... which is at least ugly.

@hyangah
Copy link
Contributor

hyangah commented Mar 1, 2016

Why not change the API to combine a result value and whatever error details
you'd like to utilize into one struct?

On Tue, Mar 1, 2016 at 7:21 AM, Kamil Dziedzic notifications@github.com
wrote:

You can't use structured error information e.g. struct that returns a
integer code and the error details etc in case of error, or nil in case of
success because gomobile strictly forbids using anything else than error
interface as second parameter.

gomobile: functions and methods must return either zero or one values, and
optionally an error

What could easily work is to allow some kind of special error struct e.g. type
GomobileError struct { Code int } the same way as for example we have
https://golang.org/pkg/net/#DNSConfigError
However, making a generic like above doesn't work in this case IMO as
android exceptions doesn't have error codes.

So maybe back to the root of the problem. Right now it's impossible to
match errors between golang code and ios/android in some systematic way. In
golang for example we can check if package exported error pointer is the
same as returned error or by using type assertion. When it comes to
matching errors between golang and ios/android we can only base on error
message... which is at least ugly.


Reply to this email directly or view it on GitHub
#14510 (comment).

__

@arvenil
Copy link
Author

arvenil commented Mar 1, 2016

Because it's even more nastier solution? gomobile implemented error interface as a second return value so it doesn't look a way to go.
But yes, that's the only option beside relaying purely on string.

@golang golang locked and limited conversation to collaborators Mar 1, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants