(v13) Error Handling in Output Plugins

This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core

This chapter describes how output plugins can report and handle errors.

An output plugin can send error messages and warnings to the RIP through the deviceDefinition 's d_error field. The RIP displays text messages and icons identifying the problem in the Output Con‐ troller. Additionally, the RIP can change the selector call sequence, stopping job output, and wait until the plugin signals that the error condition has cleared.

Generally, upon return from each plugin call, the RIP inspects the value of d_error . Depending on what it finds it might display text‐ and icon‐based messages in the Output Controller, and/or alter the selector call sequence to give the plugin the opportunity to recover from the error.

Note: Errors and warnings are signaled via d_error only. The plugin should still return NOERR from the call unless it cannot possibly recover from the error.

The RIP records the last error reported in the deviceDefinition 's d_lasterror field upon the next plugin call.

Note: For efficiency reasons there are circumstances in which the RIP may make a sequence of calls, deferring to check the error state at the end of the sequence. An example is where several calls to D_OUTPUT are made when more than one band of data is available with no intervening delay.

The RIP expects the plugin to be resilient to being called when an error state is extant, and the plugin should never “clear” d_error (or change it from one error to another) except when the RIP is requesting it so to do in a D_CLEAR_ERROR call.

Note: Errors may not be handled on D_OPEN , so the plugin should be prepared to receive D_OUTPUT , D_IDLE and D_CLOSE calls, even if it sets d_error during a D_OPEN call.