Restructure Exceptions
Keivan-sf opened this issue · comments
Currently there are no exceptions if signing process fails. Which means it'll lead to default crypto/cryptojs errors if a user was to provide a wrong key format. (which is not so much away from happening in a format like rsa in Pasargad driver).
I assume a SigningException can be suitable for the cause. Or even a default Error object with a more convenient message
For the time being, Sadad and Pasargad implement a signing process.
I'd be happy to know any other ideas and to be assigned to this issue
Thanks for the well-thought issue.
Honestly, I think we should change how the errors work for v2.
We could separate them like so:
BadConfigError: The error was caused because the developer has wrong configs for the driver. e.g. wrong credentials, empty fields that are mandatory, etc.UserError: The error was caused because the user did something wrong. e.g. didn't complete the transaction, didn't have enough funds, etc. - This error is safe to be shown to the end userPaymentGatewayError: The error was caused because the IPG did something wrong. e.g. was unavailable at that time
I'm suggesting this because I don't think if the developer cares about if the error was a verification error, payment error or a signing error - this seems like a better way to categorize them. And like you said, we can have the description on the error message.
I might be missing something though - as I haven't worked on this repo for a while now. Please let me know what you think about it!
This looks better to me as well. It will best the current error handling system. However there might be some challenges for this method.
Some APIs (e.g Pasargad) don't flatter us with any error codes. We might be able to take advantage of /checkTransactionResults route and track the transactions if there was a problem with verifying it. And it might lead us to some understanding about the origin of the problem.
In other cases though this error handling method will be quite effective. As you've mentioned, knowing whether or not to display the error to the end user is more important than where it was thrown.
Now that you've mentioned v2, I'll be opening up some issues for it. there are some methods that we can offer on some drivers.
For instance:
- Refunding method. Some banks will allow the developer to refund within a fixed amount of time (e.g it's 2h for Pasargad)
- Checking Transaction Method. This one is a little tricky. Some APIs provide it in the same route as
PaymentVerificationroute and others in a specific endpoint
Also the code is like a year old I guess it can use some small refactoring (Thanks to the tests you've written it won't be a pain). I'll open an issue for this after I'm done with RSA-xml to pem conversion
Now that the project is in the monorepo shape, Should I start getting on this issue?
Also it's easier now with zod to throw config errors. it offers a really clean way to throw custom objects
I kind of regretted doing the monorepo change... haha. I'll probably revert it.
The whole reason I did the monorepo change was because I thought we might need a separate package for NestJS - but I don't think if we do. We could just have NestJS as a peer depencendy and expose the modules and services from monopay/nestjs
Update: OK we're back on the non-monorepo structure we had before.
You can start working on this issue, that sounds great.
About the config errors. Should we just expose the Zod errors? What do you think?
Do we really need another wrapper around them?
Cause we had a wrapper around the io-ts error. (BadConfigException)
I do agree, we may let zod do its thing
I was assuming we should have validation for fields like Email or Callbackurl to make sure user is passing the right input but I think we better avoid it. There's usually some validation for it in the developers code anyway so it's kind of unnecessary lost of performance
Yeah our only concern is validating the configuration.