Error Handling

Overview

Errors, exceptions, and bugs are a part of building any application. By paying close attention to how we deal with and handle errors, we can create an application that is easy to maintain and administer. By making informed and consistent decisions in our error handling, we can give end users a superior experience, while also making it easy for the next engineer who comes along to maintain our solutions.

Errors can occur anywhere in our implementations, whether in the "point and click" administration, within our scripting or custom solutions, or within external systems that we connect with as a matter of business. Error prone operations include:

• Parsing strings into numbers
• Processing delimited strings
• Using manually entered data
• Using data from automated uploads from external systems

Administration

Don't Catch, Avoid

The first mistake many people make when dealing with errors is to simply hide them. In languages with exception handling built in, this looks like this:

//Example of what not to do
try {
somefunction();
catch(exception) {
/*do nothing!*/
}

The problem with this approach is that when things go wrong, it is difficult to identify and locate where the issue occurred. In some cases, this can hide the error so well that we don't even know it's happening until we notice data corruption or data loss.

The preferred way to deal with exceptions is to anticipate and avoid them. We can then make informed decisions about when it is appropriate to show an error to the user, and when to rely on default values or other responses. We want our code to fail gracefully - this doesn't always mean silently.

In fact, depending on the situation, it may be more appropriate to raise an error than to avoid it.

Throwing Errors to Validation Rules

In BML, we don't have try/catch or throw. But within Commerce, we can use the Advanced Validation rules to create our own custom errors. This is useful when dealing with large blocks of code like a pricing script, where it can be tricky to do fine-grained troubleshooting. This is a simple process:

1. Create a Main Document attribute.
2. Write to that attribute from your Advanced Modify rule.
3. Show the error using an Advanced Validation rule.

As an example, suppose that we reference a Data Table for a key piece of functionality in our pricing script. We know that the Data Table will be updated manually by an admin, which is an error prone process. So we can show a descriptive error message if we ever notice a problem with the data in the table:

// Commerce Library - pricing function
//before the line item loop...
errorMessages = "";
//[...]
for line in process {
//[...]
records = BMQL("SELECT Quantity from InventoryTable");
for row in records {
quantity = get(row, "Quantity");
if(!isnumber(quantity)) {
errorMessages = errorMessages + "\nInvalid value for quantity in Inventory Table: " + quantity;
errorMessages = errorMessages + " Please contact your system administrator.";
} else {
//perform operations using data
//[...]
}
}
//[...]
}
//populate attribute
resultString = resultString + "1~customErrorMessage_quote~" + errorMessages;

Now in the Advanced Validation rule we simply display any error messages that came up in the Advanced Modify:

resultString = "";
//[...] perform any other validations
resultString = resultString + customErrorMessages_quote;
return resultString;

This is a nice solution that deals with expected problems that might come up in the life of the application. We might even take it a step further, and use workflow rules to trigger an email to the system admin with our error message. The key is that we are anticipating errors and dealing with them in a way that matches the severity of the problem.

Troubleshooting

When writing your error handling, be sure to consider the process necessary to show the error. It's not going to do you any good to create a custom error message if the Advanced Modify is unable to complete without some sort of data.

It may be necessary to provide valid default data in the event of invalid data, just so that Advanced Modify can finish running and your validation rule can fire. The advantage of this is that whoever is supporting your site will have a great idea of where to get started to fix the issue.

Related Topics

See Also