Te perdiste otras partes del libro. Sí, Steven es cierto:si ocurre una excepción en un bloque, todos los efectos DML anteriores permanecen en su lugar. Sin embargo, debería haber otra mención en el libro de que cualquier ejecución de instrucción SQL o PL/SQL de nivel superior (es decir, bloque anónimo también) abre un cursor para esa instrucción y, si hay una excepción durante la ejecución del cursor, todos los efectos DML realizados durante la ejecución del cursor se revierten. Quizás un simple ejemplo te dé la pista...
En su ejemplo original, ejecutó...
BEGIN
DELETE FROM dml_exception;
raise value_error;
END;
... como la declaración de nivel superior. Sí, al final del bloque, aunque todavía dentro, tu delete los efectos permanecieron en su lugar. Sin embargo, su bloque generó una excepción que se propagó hasta el cursor de nivel superior. Por lo tanto, para adherirse a los principios de atomicity
, Oracle revirtió todos los efectos pendientes del cursor abierto.
Si llama a su bloque PL/SQL desde dentro de otro bloque PL/SQL de nivel superior, que maneja y no vuelve a generar la excepción generada en el bloque PL/SQL de nivel inferior, ...
BEGIN
BEGIN
DELETE FROM dml_exception;
raise value_error;
END;
EXCEPTION
WHEN others THEN NULL;
END;
..., entonces su delete los efectos permanecerán en su lugar. (Y dado que no hay confirmación en ese bloque, termina teniendo una transacción en curso).
