¿Por qué el bloque TRY-CATCH no está permitido dentro de las UDF?

Question

¿Por qué SQL Server no admite bloques TRY-CATCH dentro de UDF?

Si hablamos de UDF escalares, que se utilizan principalmente para cálculos y conversaciones, este bloque debe ser muy utilizado, pero no lo tenemos.

Además, ¿qué soluciones usas para esto?

Answer 1

Las UDF en MSSQL no pueden tener efectos secundarios, lo que BOL define como "cambiar el estado de la base de datos". Eso es una descripción bastante vaga, pero MSSQL aparentemente considera errores para cambiar el estado de base de datos - esto UDF no se compila:

create function dbo.foo() 
returns int 
as 
begin 
    raiserror('Foo', 16, 1) 
    return 1 
end 
go 

El mensaje de error es:

Msg 443, nivel 16, estado 14 , Procedimiento foo, Línea 5 Uso no válido de un operador de efecto secundario 'RAISERROR' dentro de una función.

Si se considera que generar un error cambia el estado de la base de datos, es probable que interceptar y manejar uno sea también. Lo cual no es una gran explicación, lo admito.

En términos prácticos, sin embargo, a menudo es mejor dejar que la persona que llama decida cómo manejar los errores de todos modos. Supongamos que escribe una función como esta:

create function dbo.divide (@x int, @y int) 
returns float 
as 
begin 
return @x/cast(@y as float) 
end 

¿Cómo manejaría el caso en que una aplicación pasa a cero para @y? Si atrapas la excepción de dividir por cero, ¿qué vas a hacer a continuación? ¿Qué valor puede devolver de la función que tiene sentido para la persona que llama, teniendo en cuenta que ni siquiera puede saber qué aplicación llama a su función de todos modos?

Puede pensar en devolver NULL, pero ¿estarían de acuerdo los desarrolladores de aplicaciones que usan su función? ¿Consideran todas sus aplicaciones un error dividir por cero para tener el mismo impacto o importancia? Sin mencionar que los valores NULL en ciertos lugares pueden cambiar por completo los resultados de una consulta, tal vez en formas que el desarrollador de la aplicación no desea en absoluto.

Si usted es el único desarrollador, tal vez no sea un problema, pero con más personas se convierte rápidamente en uno.

Answer 2

Como solución temporal, me gustaría llamar al UDF de TRY/CATCH dentro de un procedimiento almacenado.

Answer 3

Tal vez sea porque la sobrecarga es demasiado - se podría llamar a una función escalar en una columna como parte de una selección y llamarla miles de veces. Si hubiera una sobrecarga razonable para permitir la prueba/captura, la ralentizaría terriblemente.