Logging Errors to the Database

Primary mentor	N/A
Backup mentor	N/A
Assigned to	N/A

Abstract

Log uncaught exceptions to a database table, along with associated metadata (date/time, user, page and/or service, stack trace summary, unique identifier) and provide this information to users in the default error handler so that they can provide a specific error log id along with their bug report. Provide tools to mine this database table to find patterns in error messages, users who frequently hit problems, and to assist in proactively improving the system regardless of whether or not users are reporting their errors.

Project Champions

mseaton

Summary

We implemented this in our legacy system in Haiti, and it essentially involved the following:

Creation of database tables to hold the exception details

The exception_log table lists summary information and metadata about the overall exception:


exception_log (
  exception_log_id,                 -- Primary key of the table
  exception_class,    -- The specific type of exception that was thrown (eg. NullPointerException)
  message,            -- The exception message ( eg. throwable.getMessage() )
  exception_datetime, -- Timestamp for the exception
  user_id             -- References user to store which user experienced the error
)

The exception_log_detail table lists the specific stack trace information that is relevant. This might be restricted on only those parts of a stack trace that provide useful, actionable information (for example, only those classes that match a certain pattern, or only those lines of a stack trace that contain certain information):


exception_log_detail (
  exception_log_detail_id,  -- Primary key of the table
  exception_log_id,         -- References the exception_log table above
  file_name,                -- The filename extracted from the stack trace
  class_name,               -- The class name extracted from the stack trace
  method_name,              -- The method name extracted from the stack trace
  line_number               -- The line number extracted from the stack trace
)

The exception_root_cause table is used to store details about the root cause if it exists, this is important for situations where the original thrown exception is wrapped into another exception type and the actual root cause gets masked in the process, therefore it is important to capture these details too.
The use case for the root cause is that if the message for the thrown exception is blank, we can use that of the root cause and typically the root cause should be included when reporting errors or submitting tickets to jira from the module.