AEM Workbench Best Practices - Exception Handling

AEM Workbench processes do not have a built-in exception management mechanism like normal java code (try..catch..throw), which often leads to developers building applications that don't
implement solid exception handling. At 8 BIT PLATOON we've developed workbench-based systems for many years and here's how we approach the problem:

Effectively all our Workbench processes have the following two output variables:

• respCode: int (Default = -1)
• respMsg: string[255] (Default = "")

Only under very specific circumstances do we ever create a process that does not include these two output variables. When doing code review, this is the first thing I look for.

If the process executes successfully, the respCode variable must be set to 0 and the respMsg variable must be set to some suitable message

For each potential error that can occur in the process:

• the respCode must be set to a positive, non-zero integration (typically 1,2,3 etc, but these can also be unique numbers that correlate with a database of system exceptions)
• the respMsg must be set to a suitable message that describes the error

Determining whether an error has occurred depends on the specific process, but typically errors come in two forms:

• A built-in Workbench operation has thrown an exception, or
• A sub-process has returned a non-zero respCode

I'll show each one individually with an example

Built-in Operation throws an exception
Here is a screenshot of a simple process that reads a file, from the file system. If the file is not found, the exception is caught and the respCode/respMsg is set accordingly:

Sub-process returned a non-zero respCode:
Below is a screenshot that shows how exceptions from sub-processes are caught. Notice the following about the process:

• In addition to the standard respCode and respMsg variables, this process also has subRespCode and subRespMsg variable.
• When calling any sub process, the respCode and respMsg from the sub process is mapped to the parent process's subRespCode and subRespMsg variables
• The parent process-step has two branches, a "Success" branch, which has an expression and a default branch for all other cases
• The Success branches check for the expression "subRespCode=0"
• A subRespCode of -1 will indicate that the sub-process failed unexpectedly prior to setting the respCode - this is handled as an exception
• A subRespCode of any positive integer inddcates that an unhandled exception has occurred in the sub process. 

By Following the approach you can manage exceptions in even the most complex Workbench processes.

Of course, we are slowly replacing Workbench processes at our clients with AEM Workflows, however, Workbench will remain for some time to come and it always makes sense to build robust systems.