Manejo estructurado de errores en SQL embebido con la cláusula WHENEVER y el uso de DO en DB2 for i (AS/400)

Cuando trabajamos con SQL embebido en aplicaciones sobre IBM i (AS/400), es fundamental manejar adecuadamente los errores que pueden surgir en tiempo de ejecución. Para ello, DB2 nos proporciona la cláusula WHENEVER, una herramienta que permite capturar errores de forma controlada y reaccionar apropiadamente según el contexto de la aplicación.

WHENEVER permite definir acciones automáticas ante condiciones como errores (SQLERROR), advertencias (SQLWARNING) o ausencia de datos (NOT FOUND) sin necesidad de validar explícitamente el SQLCODE después de cada sentencia SQL. Aunque muchos sistemas legacy siguen utilizando GOTO en estos escenarios, una práctica más moderna y mantenible es utilizar DO, lo cual permite invocar procedimientos o controlar el flujo de forma estructurada.

1. ¿Qué es WHENEVER en SQL embebido?

WHENEVER es una cláusula que se utiliza en SQL embebido para definir qué hacer cuando ocurre una determinada condición en tiempo de ejecución:

• SQLERROR: Errores en la ejecución SQL, como violación de restricciones o problemas de conexión.
• SQLWARNING: Advertencias del motor SQL, como truncamiento de datos.
• NOT FOUND: Se activa cuando no hay registros afectados o devueltos por una operación SQL.

Su uso reduce considerablemente la necesidad de validar manualmente SQLCODE, permitiendo una lógica de control más clara y centralizada.

2. Sintaxis moderna con DO

En lugar de redirigir el flujo con GOTO, la sintaxis moderna permite usar DO, que puede invocar directamente una subrutina o controlar el flujo mediante comandos estructurados:

EXEC SQL
   WHENEVER [SQLERROR | SQLWARNING | NOT FOUND]
   DO [procedimiento() | CONTINUE | BREAK];

• DO procedimiento(): Invoca una rutina definida en el lenguaje host (ej. dcl-proc en RPG).
• DO CONTINUE: Ignora la condición y continúa la ejecución.
• DO BREAK: Rompe la ejecución del bloque actual (por ejemplo, salir de un bucle).

3. Ejemplo práctico en SQLRPGLE usando DO procedimiento()

Dcl-S IDEmp Int(10);
Dcl-S NombreEmp Varchar(50);

exec sql
   WHENEVER SQLERROR DO ManejarError();
exec sql
   WHENEVER NOT FOUND DO ManejarNoDatos();

exec sql
   SELECT nombre INTO :NombreEmp
   FROM empleados
   WHERE id = :IDEmp;

*INLR = *ON;
return;

dcl-proc ManejarError;
   Dsply 'Ocurrió un error SQL';
   // Rollback, logging, limpieza de recursos, etc.
   *INLR = *ON;
   return;
end-proc;

dcl-proc ManejarNoDatos;
   Dsply 'No se encontró el empleado';
   return;
end-proc;

Este enfoque evita saltos de flujo tipo GOTO, mejora la trazabilidad del error y separa claramente la lógica de negocios del manejo de errores.

4. Uso de DO CONTINUE y DO BREAK

DO CONTINUE:

Permite que el programa continúe su ejecución sin hacer nada especial cuando ocurre la condición. Es útil, por ejemplo, para ignorar advertencias esperadas:

EXEC SQL WHENEVER SQLWARNING DO CONTINUE;

DO BREAK:

Interrumpe el bloque de ejecución actual, y se utiliza normalmente dentro de estructuras repetitivas (bucles con cursores):

EXEC SQL WHENEVER NOT FOUND DO BREAK;

Esto es particularmente útil cuando estás haciendo FETCH dentro de un bucle, y querés salir tan pronto no haya más datos.

5. Ventajas del enfoque estructurado con DO

• Evita el uso de GOTO, mejorando la claridad del código.
• Encapsula la lógica de manejo de errores en procedimientos reutilizables.
• Mejora la mantenibilidad y legibilidad del código embebido SQL.
• Favorece buenas prácticas, especialmente en aplicaciones críticas donde la robustez es clave.
• Se alinea con un estilo más moderno de desarrollo en IBM i.

Vale mencionar que los procedimientos invocados con DO procedimiento() no aceptan parámetros, por lo que cualquier dato que se necesite debe estar en variables accesibles desde el contexto del programa (por ejemplo, variables DCL-S compartidas).

Usar WHENEVER en SQL embebido sobre DB2 en AS/400 con DO en lugar de GOTO es una forma moderna y efectiva de manejar errores sin contaminar el flujo del programa. Al delegar las acciones a procedimientos, se obtiene un control más claro y centralizado de las excepciones, mejorando la mantenibilidad del código y promoviendo un estilo más profesional y alineado a estándares actuales en entornos empresariales sobre IBM i.