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
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:
constErrCodeNotFound=1
And an error:
typeErrNotFound 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.
The text was updated successfully, but these errors were encountered:
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.
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?
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:
And an error:
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.
The text was updated successfully, but these errors were encountered: