stored procedures - predefinidas - Manejo de excepciones PL/SQL en procedimientos

procedure oracle ejemplos

Question

Esta es una especie de pregunta sobre las mejores prácticas. Tengo un bloque PL / SQL similar a este

DECLARE
--work variables
PROCEDURE p1(in_parameter1, out_parameter1, out_parameter2...) IS
BEGIN
--do stuff
--select ( ... ) into ( ... ) from t1 where ( ... )
END;
PROCEDURE p2(in_parameter1, out_parameter1, out_parameter2...) IS
BEGIN
--do stuff
--insert/update tables
--do more stuff
END;
BEGIN -- MAIN PROCESS STARTS HERE
open c1;
fetch c1 into c1RowData;
EXIT WHEN c1%NOTFOUND
--call procedure1
--do stuff
--call procedure2
--do stuff
--do stuff
--call procedure1
--call procedure2
END;
/
EXIT;

Las declaraciones en los procedimientos p1 y p2 posiblemente podrían generar excepciones (NO_DATA_FOUND, DUP_VAL_ON_INDEX, ...).

¿Cuál crees que es la mejor manera de manejar estas excepciones? ¿Deben manejarse dentro de los procedimientos o crees que debo rodear cada llamada de los procedimientos en el cuerpo principal con un bloque TRY-CATCH?

Answer 1

Debería tratar de manejar las excepciones en la fuente (es decir, dentro del procedimiento que las plantea). Esto le da mayor margen para informar dónde se produjo el problema y, por lo general, una mayor posibilidad de poder corregir el problema sin pasar un mensaje de error desagradable de Oracle al usuario.

Por supuesto, ambos pueden manejar el error y volver a subirlo si realmente lo necesita, pero como StevieG respondió, también puede generar excepciones definidas por el usuario que generalmente son más específicas de la aplicación y más útiles para sus usuarios / otro código PL / SQL.

Hay una discusión ASKTOM sobre el manejo de errores personalizados aquí: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4684561825338

Answer 2

Personalmente los atraparía dentro de los procedimientos de los que fueron arrojados. Esto significa que tiene mucho más control con respecto a cómo se manejan externamente. Por ejemplo, puede lanzarlos de nuevo como excepciones definidas por el usuario que puede embellecer con más información acerca de qué fue exactamente lo que salió mal.

''Failed to find a matching row in table a for value b''

es mucho más descriptivo fuera del procedimiento que

''no data found''

Pero esto es realmente dependiente de:

1. Los requisitos de informe de error de la aplicación de llamada
2. La funcionalidad real implementada donde ''haces cosas'' dentro de los procedimientos

Por ejemplo, supongamos que desea ejecutar el procedimiento 2 aunque el procedimiento de selección 1 no encuentre filas. Debería detectar la excepción en el procedimiento 1 e ignorarla. Si no lo hizo, se lanzará al manejador de excepciones en el procedimiento 2.

O bien, supongamos que desea que el procedimiento 1 inserte una fila en el caso en que la selección no encontró nada, en este caso necesitaría capturar la excepción y realizar la inserción en el manejador de excepciones.

Ahora, antes de que nadie se me ocurra, no recomiendo que uses manejadores de excepciones para controlar el flujo de ejecución dentro de tu código, estos ejemplos son teóricos, pero ojalá entiendas la idea ...

Answer 3

Lo mejor es cuando se manejan las excepciones dentro del procedimiento. Será resultado rápido. No solo eso, si reutilizamos el mismo procedimiento en algunas otras funciones, tampoco necesitamos manejar excepciones. Mi punto de vista, las excepciones que puedo manejar dentro del procedimiento en sí mismo es el mejor.