We use .code as a way to identify certain error conditions independent of the error message (which may be localised into the users' language) - ERR_STREAM_RESET, ERR_INVALID_PARAMETERS, etc.
This property was largely inspired by node.js' use of .code, and is not idiomatic JavaScript which seems to have subsequently coalesced around the .name property of the Error type for this sort of thing instead.
There's a ongoing effort to introduce error codes to libp2p, and supplying any encountered code to the application is marked MUST.
The natural thing of js to do would be to throw an Error with the appropriate numeric .code property, which conflicts with the current implementation.
We should refactor our use of errors to use a .name string property (e.g. StreamResetError, InvalidParametersError, etc) which frees up the .code property to receive an error code from the remote node specifying why the stream was reset.
This is a breaking change that would cause libp2p@2.0.0 to be released.
We use
.codeas a way to identify certain error conditions independent of the error message (which may be localised into the users' language) -ERR_STREAM_RESET,ERR_INVALID_PARAMETERS, etc.This property was largely inspired by node.js' use of
.code, and is not idiomatic JavaScript which seems to have subsequently coalesced around the .name property of theErrortype for this sort of thing instead.There's a ongoing effort to introduce error codes to libp2p, and supplying any encountered code to the application is marked
MUST.The natural thing of js to do would be to throw an Error with the appropriate numeric
.codeproperty, which conflicts with the current implementation.We should refactor our use of errors to use a
.namestring property (e.g.StreamResetError,InvalidParametersError, etc) which frees up the.codeproperty to receive an error code from the remote node specifying why the stream was reset.This is a breaking change that would cause
libp2p@2.0.0to be released.