#Error Handling

Introduction

If you're solving complex problems in ObjectScript, you probably have a lot of code that works with %Status values. If you have interacted with persistent classes from an object perspective (%Save, %OpenId, etc.), you have almost certainly seen them. A %Status provides a wrapper around a localizable error message in InterSystems' platforms. An OK status ($$$OK) is just equal to 1, whereas a bad status ($$$ERROR(errorcode,arguments...)) is represented as a 0 followed by a space followed by a $ListBuild list with structured information about the error. $System.Status (see class reference) provides several handy APIs for working with %Status values; the class reference is helpful and I won't bother duplicating it here. There have been a few other useful articles/questions on the topic as well (see links at the end). My focus in this article will be on a few debugging tricks techniques rather than coding best practices (again, if you're looking for those, see links at the end).

In this article, exceptions are covered.

Working with Exceptions

Instead of returning a %Status response, you can raise and throw an Exception. You are then responsible for catching the exception and validating it. IRIS provides five main classes to handle exceptions effectively. Additionally, you can create custom exception class definition based on your needs.

Let's start with a simple motivating question: over the past 14 days, what are my most common errors in the Application Error Log?

I came up with a challenge for myself to come up with a way to make a variable watch itself for a certain value and do something when it hits that value without having to check it every time something touches it. Basically, a way to say "if at any point during the execution of this code, if x = 0 (or whatever the condition is) do this thing." The class I ended up with watches a %Status:

Hi folks!

It's not an innovation, but often I saw not a very informative Error page for CSP apps and got it for myself. Something like that:

Some of you might not be aware of this "Known Issue/Limitation" when defining a BPL-based Business Process.

And those who are not might have encountered this (somewhat "unpleasant" error):

Hi Developers!

As you know the application errors live in ^ERRORS global. They appear there if you call:

d e.Log() 

in a Catch section of Try-Catch.

With @Robert.Cemper1003's approach, you can now use SQL to examine it.

Inspired by Robert's module I introduced a simple IRIS Analytics module which shows these errors in a dashboard:

ObjectScript has at least three ways of handling errors (status codes, exceptions, SQLCODE, etc.). Most of the system code uses statuses but exceptions are easier to handle for a number of reasons. Working with legacy code you spend some time translating between the different techniques. I use these snippets a lot for reference. Hopefully they're useful to others as well.