Best Practices For System/Application Level Error Handling
  • 13 May 2022
  • 2 Minutes to read
  • Dark
    Light

Best Practices For System/Application Level Error Handling

  • Dark
    Light

Article Summary

Overview

This article serves as an overview of best practices for error handling for a Server in Production. This article outlines an example for how errors can be managed across a Server. This is necessary because certain errors cannot be caught/managed within Decisions or are better managed with other tools.

The following diagram outlines three different tiers that comprise this error handling approach:



Uptime

The Decisions Login page shows an error and exception message when Service Host Manager is down to inform the user that the service cannot be reached, not as a form of monitoring. It is recommended to use an Uptime Monitoring Tool to monitor the status of the site.

These tools check a web page at regular time intervals (usually every five to 15 minutes), then monitor the response. If the response returns an Error or the request couldn’t reach it, the tool sends notifications to inform of the outage so that the Administrator can take appropriate action. 

Some examples of Uptime Monitoring Tools are Nodeping (used to monitor hosted environments) and Pingdom Service Uptime Host (Tracker).

Process Errors

Process Errors are errors occurring at the Workflow level in Decisions. These errors can make their way into System Level Logs, but cannot necessarily be handled at the System Error Level. These errors should be managed within Decisions by configuring Flows to catch Unhandled Exceptions using either the Catch Exception step or the On Exception outcome path of a step. For more information, please visit the Exception Handling Best Practices article.

For additional information on Process Error Handling, see Exception Handling Best Practices.



System Errors

These errors can be caught and handled at the System Level, but not in Decisions at the Process Error Level. For example, if a Flow is triggered by an API Call, but the call is poorly formatted and does not reach Decisions, there is no way that Process Level Error Handling can capture an Exception.

One way to manage these errors is to use a Log Ingestion Tool. These software tools are capable of reading into errors from Decisions at a more granular level than Decisions exception handling. They take in Logs from Decisions and other sources, filtering out unnecessary information, combining the relevant pieces to provide detailed System Level information for an Error Event.

For these tools to be beneficial, they need to be configured to ingest more than just the Decisions Logs. A Log Ingestion Tool could be configured to take in data from the Decisions Service Host Manager Logs, IIS Logs, LM Logs, Event Viewer Logs, SQL Server Logs, etc. Many of these tools will generate Reports on the information collected from Error Events.


Was this article helpful?