What is the recommended way to handle errors inside a Business Process?

For a BPL business process, the documented practice is to use BPL’s own error-handling model: define <scope> blocks with <faulthandlers>, and use <catch> for specific named faults or <catchall> for anything not specifically matched. When a fault is thrown, control passes to the matching fault handler in that scope; if no specific <catch> matches and a <catchall> exists, the <catchall> is used. [1][2][3][4]

If you are deciding between “Try/Catch inside the BPL” and native BPL handling, the material here points to BPL fault handlers for BPL processes rather than ObjectScript TRY/CATCH as the mechanism described for BPL itself. It also states that error handling in a BPL business process happens automatically, without needing to test or set the status value in normal BPL source code. [5][6][7][8][9]

If your process needs to stop with an error in a controlled way, the documented way is to set status to a failure value. When status acquires a failure value, InterSystems IRIS immediately terminates the business process and writes the corresponding text message to the Event Log. The documentation explicitly says this is the best way to cause a BPL business process to exit immediately, but gracefully. Also, a <call> automatically places the returned %Status into status, so failures from downstream business hosts propagate automatically into the BPL. [6][7][8][9]

For unexpected errors, you should not rely only on automatic logging if you have defined <faulthandlers>. The documentation explains that when scopes include <faulthandlers>, InterSystems IRIS does not automatically output the system error to the Event Log the same way it does when there is no scope/fault handling. In that case, it is up to the BPL developer to emit <trace> messages for unexpected errors. [1][2][3][4]

So, from the sources available here, good practice is:

• structure error-prone sections inside <scope> blocks
• handle known business faults with specific <catch>
• include <catchall> for unexpected cases
• use status failure when you want the process to terminate gracefully
• add <trace> output in fault handlers so unexpected errors are visible in the Event Log [1][2][3][4][6][7][8][9]

Note: If a is provided, it must be the last statement in the block. All blocks must appear before . [1][2][3][4]

Note: Error handling for a BPL business process happens automatically without your ever needing to test or set the status value in the BPL source code. The status value is documented here in case you need to trigger a BPL business process to exit under certain special conditions. [6][7][8][9]

Caution: Like all other execution context variable names, status is a reserved word in BPL. Do not use it except as [6][7][8][9]

The retrieved documents do not provide guidance that the built-in Production retry mechanism should be the primary or recommended general strategy for handling errors inside a Business Process, and they do not describe returning an error response to the caller as the general best practice. The guidance present is centered on BPL fault handlers, automatic %Status propagation, graceful termination via status, and explicit tracing/logging in fault handlers. [1][2][3][4][6][7][8][9]

Sources: