New error handling method

[Keivan-sf]

resolves #23

I've separated errors into 3 different exception objects such as discussed in #23 :

• BadConfigError: Denotes an error caused by wrong types or configurations provided by the developer. It could be an error from IPG (e.g. wrong API key) or it could be caught in the application itself (e.g. amount must be a number)
• UserError: Denotes an error caused by the end user due to a behavior. (e.g. cancelling the transaction)
• GatewayFailureError: Denotes an error either caused by a failure from gateway or an unrecognizable reason. (e.g. internal gateway error)

All errors extend an abstract class called MonopayError which offers some properties:

• message ?: It's a string|undefined property which contains the error message if there is any
• isIPGError: It's a boolean property which shows whether the error was thrown from the IPG or the application itself
• isSafeToDisplay: it's a boolean property showing whether the error message is ok to be shown to the end user or not

For the drivers that lack error codes, exceptions that are mostly thrown are GatewayFailureError's. Due to them being unrecognizable.

TODO

• In IPG's documentations, some errors are just called Payment failure. I'm having trouble categorizing them and I think I've been inconsistent about them in code as well. We need to make a decision about them. My initial idea is we count them as GatewayFailure's. Because we probably can't know if it was the IPG that caused the error or the user. It just seems unrecognizable
• Documentations need to be updated
• We might want to mention IPG error codes in the message. So the developers could easily follow along with the error in the official IPG documentation

[Keivan-sf]

I've had the same thoughts about error codes being in a separate field as well. However it might lead to some confusion. For example if a developer sees both isIPGError and IPGErrorCode , they would assume the IPGErrorCode will be always available when isIPGError is true. Which is clearly not the correct approach in so many cases (e.g. internal errors , lack of error codes etc.) But on the other hand developers might want to make decisions based on them so it's really beneficial if we could somehow provide them. I thought maybe we could have an IPGResponse but we might get an empty response in some cases as well. Also it's an extra interface to deal with

I'm kinda unsure what we should do but I think providing a string|undefined field like errorCode is a good choice. If you're having the same thoughts I shall get on it

[alitnk]

That sounds good - Maybe we can add a jsdoc note and make these concerns clear

[alitnk]

lgtm!