ToError FromError Protocol Changes #34
Merged
+418
−425
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
FromError/ToError
fromError will need to be any -> JSONValue
If it is an error or a serialisable value it must be serialised, otherwise throw a TypeError indicating that it cannot
toError will need to be JSONValue -> any
unknown values will be thrown upwards as is, as the peer is able to throw anything they want that is JSON serializable
if the JSONValue passed into toError is a serialized error, and the error.type cannot be found, it will be deserialised into a generic Error
When fromError throws a TypeError, this will be dispatched on the RPCServer instance, to notify the user that most likely one of their handlers is throwing an non-serialisable value. This is also wrapped in an ErrorRPCRemote and sent to the client so that they know that an internal server error has occured due to an attempt to throw.
Error Object
There have been some changes regarding how errors are mapped to JSON-RPC messages.
A typical JSON-RPC message containing an ErrorRPCRemote would look like the following:
This means that all user-thrown application-level errors are now mapped to a type on an ErrorRPCRemote error object, rather than to an error object directly like before. This change was possibly due to a misunderstanding when toError/fromError was initially being speced out. But please correct this if that is not the case.
As of current, the only protocol-level errors that get transmitted between peers are ErrorRPCRemote, which is a wrapper for an application level error, with all other errors only being thrown on the client. However, the aforementioned change may help if we ever decide to introduce protocol-level errors that are transmitted.
Also, the error object.message now carries the error.message rather than the error.description. This has been done for the sake of convenience, it making more sense, and also the fact that the descriptions in all the Errors that extend ErrorRPCProtocol have a static description.
Issues Fixed
Tasks
Final checklist