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 built-in error code range #943

Closed
Tracked by #8225
mtrezza opened this issue Mar 8, 2020 · 7 comments · Fixed by #941
Closed
Tracked by #8225

Define built-in error code range #943

mtrezza opened this issue Mar 8, 2020 · 7 comments · Fixed by #941

Comments

@mtrezza
Copy link
Member

mtrezza commented Mar 8, 2020

Is your feature request related to a problem? Please describe.
It can be useful to throw a custom Parse.Error in cloud code and handle that specific error on the client side by error code.

For example an error, when a user account is banned.

throw new Parse.Error(9001, "account banned");

If a new built-in Parse Error is introduced in the future, it can conflict with the custom error code. There is currently no way to prevent such a future conflict as the range for built-in error codes is not defined in the docs.

Describe the solution you'd like
Define the built-in error code range in the docs ...-999, so custom error codes won't conflict.
Currently, built-in Parse Error codes have up to 3 digits.

Alternatives
Reserve an error code range for custom errors, e.g. 9001-9999.

Additional context
Not sure in which range adapters (push adapter, etc) are currently throwing.

@mtrezza mtrezza changed the title Reserve custom error code range Define built-in error code range Mar 8, 2020
@SebC99
Copy link
Contributor

SebC99 commented Apr 3, 2020

I agree, having the 141 error for each cloudFunction error is hard to deal with. We have to test for 141, then go inside the error, to find another code, which is not very convenient...

@stale
Copy link

stale bot commented May 19, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot closed this as completed May 27, 2020
@mtrezza
Copy link
Member Author

mtrezza commented Jun 3, 2020

OK, then I guess we only have to add a range to the docs.

I noticed that 3rd party modules may want to use custom error codes too. So should we define a suggested range for these as well?

  • Parse Server and Parse Platform modules: ... - 4999
  • 3rd party modules: 5000 - 8999
  • Developers: 9000 - ...

@SebC99
Copy link
Contributor

SebC99 commented Jun 3, 2020

Well, the only change to do in the docs in my opinion is to add something about the usage of new Parse.Error(code, message) which let developer uses any code they want.

@mtrezza
Copy link
Member Author

mtrezza commented Jan 26, 2023

@parse-community/server any thoughts on this?

The current suggestion is to define the following error code ranges:

  • Parse Server and related modules: <= 4999 (incl. neg. numbers)
  • 3rd party modules (not managed by Parse Platform, self-managed by community on first come first served basis): 5000 - 8999
  • Developers (custom app errors): >=9000 <=9999

@mtrezza
Copy link
Member Author

mtrezza commented Jan 3, 2024

After some more thought, I don't believe that the "3rd party modules" range is feasible because it would have to be community managed, for which I don't see a concept. So I would say that for now we'll just specify that developers have a reserved error range >=9000 <=9999 which they can use for custom errors. Neither Parse Server now any Parse Server adapter or module should use that range, and an 3rd party module should not use the range to prevent conflicts.

@mtrezza mtrezza transferred this issue from parse-community/parse-server Jan 14, 2024
@mtrezza mtrezza linked a pull request Jan 14, 2024 that will close this issue
@mtrezza
Copy link
Member Author

mtrezza commented Jan 14, 2024

Closing via #941

@mtrezza mtrezza closed this as completed Jan 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants