ErrorHandlingby Donovan Chandler
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
— Martin Golding
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.
- 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.
- 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.