0

I am creating a wrapper API over a payment API that is pretty hard to use. All sort of things can go wrong when you do payment transactions; there is a problem with the card, the payment was refused by the clients bank, 3D secure issue and the list goes on (around 20 error codes). From the payment API this information is provided in a normal String field. The error code will e.g. be Card_not_eligible.

What I want to do is to provide a better way to handle such errors. I have been thinking of creating own exceptions for each of these error codes. Does this sound crazy? If not would you use checked or unchecked exceptions? Forced catch of 20 errors or more is probably not an good idea?

Or do you have a better solution for this type of error handling?

LuckyLuke
  • 47,771
  • 85
  • 270
  • 434
  • Why would you want to use an exception for that? The error code is sufficient enough to indicate the state of the result, and generating an exception for those possible states would be prohibitively expensive during a normal runtime of your application. – Makoto Jun 14 '14 at 17:06
  • An enum for each error code will be more elegant. It will also allow you to add an enum to indicate everything went correctly which is easy to work with. – Jeroen Vannevel Jun 14 '14 at 17:08
  • @Makoto Yeah, maybe creating an enum would be better. I also have another field that either contain `success` indicating that the transaction went fine, or any other string indicating that something went wrong. Would you throw an exception then? – LuckyLuke Jun 14 '14 at 17:13
  • No. I'd only throw an exception if there was something wrong with the data I had an expectation for (then I'd fix the expectations). Exceptions cover *exceptional* behavior. I'd expect auth errors and other generic errors with credit cards to be commonplace enough not to warrant the expense of creating a stack trace, all because they fat-fingered their CVV number. (Disclosure: I work with a system that hands off this info to a payment processor. Exceptions aren't used to indicate [typical] errors with authorization. Wild issues, sure. But not mundane stuff.) – Makoto Jun 14 '14 at 17:18
  • @Makoto So what would you do then? Create an enum `TransactionStatus` with success and failed? Or another way? – LuckyLuke Jun 14 '14 at 17:22
  • It's up to you. Enums are fine. – Makoto Jun 14 '14 at 17:24
  • @Makoto So an exception with the data would have been...? Could you give an example? – LuckyLuke Jun 14 '14 at 17:29

1 Answers1

2

Question 1

I have been thinking of creating own exceptions for each of these error codes. Does this sound crazy?

It depends on if these error codes refer to exceptional behavior as yet pointed out by Makoto. For example if an API returned me an error code about a server connection broked down I generally would handle such exceptional behavior by throwing an exception. But if that server was powered by Bicycle Generator Project it's clear that the connection might be down, so in such case there isn't any exceptional behavior to handle and I wouldn't throw any exception.

So your solution sounds crazy to me when some of these error codes aren't exceptional behavior.

Question 2

If not would you use checked or unchecked exceptions?

This question has been just answered:

Question 3

Forced catch of 20 errors or more is probably not an good idea?

It seems smell code.

Question 4

Or do you have a better solution for this type of error handling?

You might group error codes in families:

  • codes that are not recoverable exceptional behaviors --> a single exception for all
  • codes that are recoverable exceptional behaviors --> a single exception for each
  • codes that are not exceptional behaviors --> not any exception
Community
  • 1
  • 1
taringamberini
  • 2,719
  • 21
  • 29