Define built-in error code range

[mtrezza]

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.

[SebC99]

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]

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.

[mtrezza]

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]

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]

@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]

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.