Closed gregwebs closed 1 year ago
I'm not sure I'm seeing the utility in having string versions of the error constants. If you want user facing errors it would be better to have a map of constants to strings. Unless the libphonenumber library offers similiar functionality I think I would lean toward not adding this.
I agree that for end users you would want to send the codes to the front-end and do localization, etc.
The intent of this is not for user-facing errors. It's for putting an error into our logs or otherwise being able to use them internally to quickly see why a phone number was rejected.
I can see the value in maintaining a strictly compatible API. It might be useful then to export a separate package (in this same repo though) that has functionality like this that is not present in the original library.
However, I think there is a way to get string representations automatically from the original Java code?
We're leaning to toward not adding the extra complexity here. Those constants don't change very often if ever so you can just map them to get something more descriptive for logs.
I would like to be able to explain why a phone number is not valid as per #125 This helps.