So your Shopify app has launched, you’re getting customers, and life is good.
That is, until you get that email from Honeybadger that there was a Ruby exception in your app.
No big deal… until 15 seconds later you get a third, and a fourth, and a fifth.
I’ve seen and heard this scenario play out many times in the past. Developing a Shopify app can be complex but many times developers forget to handle error states.
This results in a launch where instead of many emails from happy customers, you get emails from your exception handling service and unhappy customers.
To help that, here’s a list of the various exceptions you might encounter when developing a Shopify app.
InMemorySessionStore::EnvironmentError – Occurs when the InMemorySessionStore is used in production. By default ShopifyApp generates a
SessionStorage class that uses ActiveRecord but if you created a custom one or changed it this could be raised.
ShopifySessionRepository::ConfigurationError – Occurs when the configured session storage class (
SessionStorage) isn’t configured.
ShopifyAPI::ValidationException – Occurs when the API response for the access token doesn’t validate with the HMAC and is a possible malicious login.
RuntimeError – Happens when the API response for the access token isn’t successful (e.g. not a HTTP 200) as part of ShopifyAPI::Session
ArgumentError – Happens when adding metafields to a new object before the object is saved (e.g. Product).
ShopifyAPI::Base::InvalidSessionError – Happens when you try to activate a session (
activate_session) that is nil.
ShopifyAPI::Limits::LimitUnavailable – Raised when an API response doesn’t include the Shopify API call limit HTTP header and the ShopifyAPI::Limits class is queried.
In the ActiveResource gem, a REST web service is wrapped with some Ruby classes to make it easier to consume.
RuntimeError – Occurs when trying to call
first_or_initialize on resource classes that don’t allow creation.
ActiveResource::TimeoutError – Occurs when the request takes too long and times out.
ActiveResource::SSLError – Occurs when an OpenSSL::SSL::SSLError is raised.
ActiveResource::ConnectionError – Occurs when the server responds with an unfamiliar response code. This also serves as the parent error class for the HTTP errors below.
ActiveResource::Redirection – Occurs when a redirection occurs (HTTP 301, 302, 303, 307). It will usually redirect properly.
ActiveResource::BadRequest – Occurs when a HTTP 400 error occurs.
ActiveResource::UnauthorizedAccess – Occurs when a HTTP 401 error occurs, usually when there is an authentication problem.
ActiveResource::ForbiddenAccess – Occurs when a HTTP 403 error occurs, usually when there is an authorization problem.
ActiveResource::ResourceNotFound – Occurs when a HTTP 404 error occurs, when a resource is missing.
ActiveResource::MethodNotAllowed – Occurs when a HTTP 405 error occurs, when the wrong HTTP verb is used (e.g. GET, POST, PUT, DELETE).
ActiveResource::ResourceConflict – Occurs when a HTTP 409 error occurs, usually from submitting outdated data.
ActiveResource::ResourceGone – Occurs when a HTTP 412 error occurs, when the resource is gone.
ActiveResource::ResourceInvalid – Occurs when a HTTP 422 error occurs, usually when submitting a resource to the server that is invalid or incorrectly formatted. Can sometimes be automatically caught by ActiveResource validations.
ActiveResource::ClientError – Occurs when any other HTTP 400 series error occurs.
ActiveResource::ServerError – Occurs when any HTTP 500 series error occurs.
ActiveResource::MissingPrefixParam – Occurs when prefix params are defined but not set (i.e. missing).
Remember, each of these libraries sits on top of the other and potentially other libraries. So an exception that occurs in ActiveResource will bubble up through ShopifyAPI and ShopifyApp and finally cause the exception in your app. Don’t forget to watch for and rescue potential lower level exceptions.
Now armed with this list you can think about how to handle these Shopify exceptions in your app.