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
Change application reserved error code range #184
Conversation
We now have codes up to 204, so application needs to start at 205.
Should we bump this number to 300 to allow us to add more error codes? |
Protocol.md
Outdated
@@ -349,7 +349,7 @@ The Error Data is typically an Exception message, but could include stringified | |||
| __RESERVED__ | 0xFFFFFFFF | __Reserved for Extension Use__ | | |||
|
|||
__NOTE__: Values in the range of 0x0001 to 0x00FF are reserved for use as SETUP error codes. Values in the range of | |||
0x00101 to 0x001FF are reserved for connection error codes. Values in the range of 0x00201 to 0xFFFFFFFE are reserved for application layer | |||
0x00101 to 0x001FF are reserved for connection error codes. Values in the range of 0x00205 to 0xFFFFFFFE are reserved for application layer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the intent was that errors were in distinct blocks, somewhat like 2XX, 3XX, 4XX, 5XX in HTTP.
So your suggestion to go to 0x300 seems like the only sensible approach. Although should probably be 0x301 as we skip X00 for all other ranges.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0x301 seems good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. 0x301.
@tmontgomery what do you recommend? |
Saving some space is good. 0x301 should be OK. |
Updated to 0x301. |
Protocol.md
Outdated
@@ -349,7 +349,7 @@ The Error Data is typically an Exception message, but could include stringified | |||
| __RESERVED__ | 0xFFFFFFFF | __Reserved for Extension Use__ | | |||
|
|||
__NOTE__: Values in the range of 0x0001 to 0x00FF are reserved for use as SETUP error codes. Values in the range of | |||
0x00101 to 0x001FF are reserved for connection error codes. Values in the range of 0x00201 to 0xFFFFFFFE are reserved for application layer | |||
0x00101 to 0x001FF are reserved for connection error codes. Values in the range of 0x00301 to 0xFFFFFFFE are reserved for application layer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This text currently leaves a gap since it doesn't describe 0x00201 to 0x002FF. Are these predefined application layer errors? App error, rejected, canceled.
0x00301 to 0xFFFFFFFE are custom application layer exceptions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. 0x201 to 0x301 should be marked for later use in future versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've confused me more! But it's late here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry. Meant that those (if I recall correctly) are for space for use by later versions of the protocol. "Reserved for future use".
Is this ready for merging? |
No, I think it should be changed to explain the 4 ranges starting custom application errors at 0x0205 seems like it needlessly precludes the spec from ever defining more. |
Updated the NOTE wording, should be ready now. |
We now have codes up to 204, so application needs to start at 205.