Exception handling

[matt-halliday]

I'm trying to handle exceptions from TaxJar but I'm unable to effectively due to a single exception for all issues. For example, an invalid address is a very different scenario to a country not being supported in terms of fallback/actions to take.

Do you have any suggestions on how one might catch these and act accordingly? I can't see that there's an endpoint to check whether a country is supported up-front to get around the issue that way.

Do I need to interrogate/case switch on a strstr of the exception message? Are these likely to ever change?

[fastdivision]

@matt-halliday Completely agree that we need to provide better exceptions for API errors. At the very least separate the error status code from the message into an array or something. That way you can check for specific codes listed here instead of using strstr. I'll try to do this early next week.

At this time we return a non-nexus response for unsupported countries, not an error:

{
  "tax": {
    "amount_to_collect": 0,
    "freight_taxable": false,
    "has_nexus": false,
    "rate": 0,
    "tax_source": null,
    "taxable_amount": 0
  }
}

Invalid addresses will return a 400 Bad Request, so you'll be able to look for a 400 status code once I release an update.

[fastdivision]

getStatusCode method added to v1.5.0. See new README for more info!

[matt-halliday]

Good job! Thanks - that will help with the orders for sure. Any suggestions for SmartCalcs calls in a similar sense? I guess we're sort of doomed as the API simply returns the following:

{
  "error": "Bad Request",
  "detail": "CN is unsupported country",
  "status": 400
}

[matt-halliday]

Or is the status always 400 for invalid addresses in this context too?

[fastdivision]

@matt-halliday You'll get a 400 error code for invalid zip and state combos along with a couple other things mentioned here: https://developers.taxjar.com/api/reference/#400-bad-request

If you need to individually parse these 400 errors, I don't believe there's a better way to do it at this time. We'll have to consider more granular error responses in a future update to our API.

[matt-halliday]

Thanks @fastdivision - I'll do something on the string for non-US addresses for now and keep an eye out for updates - hopefully this will at least give some visibility over any possible breaking changes should those strings change in an update. Have a great rest of week!