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

Define errors and their codes in the IDL #11

Open
colega opened this issue Dec 22, 2017 · 2 comments
Open

Define errors and their codes in the IDL #11

colega opened this issue Dec 22, 2017 · 2 comments

Comments

@colega
Copy link

colega commented Dec 22, 2017

I'd like to be able to define the error codes in the IDL, and once there, it would be cool to automatically build the errors with those codes.

For example, if I define in myservice.idl

error NotFound = 1

In case of Go code I would have automatically generated a constant:

const ErrCodeNotFound = 1

And an error:

type ErrNotFound barrister.CustomJsonRpcError

And the automapping code needed (err code <=> err type) so I could return the *mypkg.ErrNotFound from my service implementation and it would be returned as *mypkg.ErrNotFound on my client side.

Of course this is cross-platform, in case of Java or PHP, for example, a NotFoundException would be thrown, etc.

This could be gradually introduced in the languages, as languages with lack of this support could use the error codes included in the IDL just like documentation and base their implementation on those codes.

@coopernurse
Copy link
Owner

Is there any link between interface functions in the IDL and these error constants? For example, do you want the runtime bindings to enforce that a particular function can only raise particular errors and not others?

I think this is an interesting idea, but I'm not sure what the dynamic language bindings would do with this information, if anything.

Let's keep discussing.

@colega
Copy link
Author

colega commented Jan 22, 2018

I think that we would need to define which functions can return which error: it would be a good documentation and languages like Java would have the exceptions defined in the signature.

I don't understand very well the second problem you mention, could you explain a little bit more please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants