Skip to content
This repository has been archived by the owner on Jun 28, 2024. It is now read-only.

Adding custom error messages for front end errors

Adam M. Holmes edited this page Mar 28, 2017 · 2 revisions

Adding custom error handling for front end errors

Bonnie uses Costanza for handling client side errors (particularly JavaScript). When an error occurs in the front end, the error is passed to Costanza by Thorax, and is sent to the backend. The backend attempts to make better sense out of the error, and returns a more detailed description (if possible). The backend will also send an email to the development team if enabled and running in production mode. The front end then takes this description and alerts the user to the error.

How to add custom error handling

Lets say we have a block of code (CoffeeScript) such as:

nullVariable = null
nullVariable.bad = 1

This code would cause a JavaScript error similar to (in Chrome):

Uncaught TypeError: Cannot set property 'bad' of null

In order to describe this error better, we can define it inside of a Costanza run block, as such:

Costanza.run 'bad-code-block', {sample_data: 'more info...'}, () =>
  nullVariable = null
  nullVariable.bad = 1

The 'bad-code-block' parameter is the definition for this section of code, and is what indicates to the backend where the code went wrong.

The {sample_data: 'example'} parameter is a way to pass custom information about the section to the backend. This is particularly useful if you want to pass things like a measure id {cms_id: @measure.get('cms_id')}, the name of a data criteria {data_criteria: @data_criteria.id}, etc.

The next step is to define how the error should be handled in the back end. In the app/helpers/error_helper.rb file, add a new when /<section name>/ block to the case statement inside the describe_error method. For our previous example, this might look something like:

when /bad-code-block/ # This should contain what you set the section name to
  {
    # This is the error details that will appear to the user
    title: 'Error!',
    summary: 'uh oh...',
    body: 'Tried to access a property of a null object! More info: ' + error_info[:sample_data] 
  }

Notice the usage of error_info[:sample_data]. :sample_data comes from what we defined in the section definition in the front end. Lets say we wanted to write a custom error message with the context of a measure. Including the measure id would allow us to write a more helpful error message that would tell the user exactly what measure is causing issues.

This will then cause a flash message to the user containing the error you have defined.