A modular open-source logging framework for FileMaker.


  • Logger module: Provide an interface for logging.
    • Call this module from any script you want to create a log entry from.
  • Log Writer modules: Save log data to a single destination.
    • Call Log Writers from the Logger module.
  • Log Viewer modules: View log data.
    • Provide a user interface for viewing log data.

File List

  • Log.fmp12: Main file for this project.
    • This file can be included with your current application to handle all your logging needs. It has been designed as both a self-standing logging application as well as an example file/documentation for the included Log-related modules.
  • LogWriters directory: Additional Log Writer modules.

Getting Started

Most documentation for this project exists in the READ ME scripts in the Log.fmp12 file:

  • File Module > READ ME
  • Modules > Logger > Logger: READ ME
  • Modules > Log Writer: FM > Log Writer: FM: READ ME
  • Modules > Log Viewer: FM > Log Viewer: FM: READ ME

Consider using additional LogWriters. View the READ ME scripts in each of those files if you choose to implement one.



View it on GitHub


Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
— Martin Golding

Error log layout

Error log layout


Your code is at some point going to fail you and your users. Some people don’t bother to trap for errors while others check every single action. This module is for the rest of us – those who want moderate functionality without being overburdened with extra script steps and decisions.

The module provides two primary scripts; one for logging errors to a table, and another for displaying errors to the user. Much of the power in this module is in the conventions it proposes.

Guiding Assumptions

  • Error handling should require very little overhead on the developer’s part. It should be habitual.
  • Error handling should not distract from the overall goals of the code.
  • Errors should be logged as close to the event as possible. This allows us to gather better diagnostic information and prevents other errors from interfering.
  • Errors should be reported as close to the initiating action as possible. This allows errors from a generic subscript to bubble up to the button script, for example, where it can be customized for the context.
  • Any particulars about an error (how to abort, message to the user, workflow decisions, etc) should be handled where the affected logic resides. In other words, it should be transparent and customizable for the developer – not buried in a subscript somewhere.

How It’s Used (In a Nutshell)

  • Scripts are wrapped in a single-pass loop so that it’s easy to skip straight to error handling and clean-up.
  • Error codes are always posted to $_error.
  • If you want to display a message to the user, post it to $_error_message.
  • All scripts check for and log errors just before exiting.
  • User-facing scripts check for error messages to display to the user. A subscript may declare an error message, but it passes the message up the chain for the user-facing script to use or modify.
  • When presented with an error dialog, the user can choose to email a bug report to the admin.
  • All errors are logged to a table along with diagnostic information.


See the README script for installation instructions.

Release History

  • 1.0.0 – 11/27/13 – Initial release
  • 1.0.1 – 11/30/13 – Respects open records
  • 1.0.2 – 12/04/13 – Error dialog allows user to press “Report” and email details to admin
  • 1.0.3 – 12/04/13 – Upgraded ParamConverter to 1.0.2; Enhanced control over error display
  • 1.1.0 – 08/19/14 – Restore original capture state; Don’t show dialogs when Error Capture is set to On


Download the latest version on GitHub.

The demo below provides additional examples that demonstrate more robust parameter parsing. The additional examples use the Six Fried Rice parameter format, so they also employ the wrapper scripts in this module.

ErrorHandling 1.0.3 Enhanced