Detectar errores en todas partes

La gestión de errores es a menudo una parte limitante del desarrollo en todos los lenguajes. En 4D, si olvida llamar a un método de gestión de errores en un nuevo proceso/trabajador o utiliza componentes que no gestionan errores, el diálogo de error incorporado de 4D puede aparecer al usuario final. A los desarrolladores 4D les gustaría capturar todos los errores en todos los contextos para evitar mostrar este diálogo de error incorporado de 4D.

Veamos cómo podemos manejar este comportamiento con 4D v19 R8.

Demo de manejo de errores

Manejador global de errores

Hasta ahora, la mejor práctica para manejar errores en un contexto de ejecución era utilizar el comando ON ERR CALL y pasar el manejador del método como parámetro. Sin embargo, este método de error era llamado sólo en el contexto de proceso actual.
A partir de 4D v19 R8, también puede definir un manejador de error global que será eficiente para todos los contextos de ejecución. Si olvidara definir un manejador de error local en un nuevo proceso/trabajador, el manejador de error global sería invocado automáticamente. Así que, para salvar tu aplicación, puedes definir tu manejador de errores global en el método de base de datos On Startup, por ejemplo.

ON ERR CALL("myGlobalErrorHandler"; ek global)

Pasar un método de error para ser llamado en el proceso actual sigue siendo eficiente. Lo renombramos como manejador de errores local.

ON ERR CALL("myLocalErrorHandler")
// equivalent to:
ON ERR CALL("myLocalErrorHandler"; ek local)

Tenga en cuenta que el manejador de error local todavía se invoca si está definido, incluso si se define un manejador de error global, por lo que sus manejadores de error locales definidos se ejecutarán como de costumbre. El manejador de errores global es invocado sólo si no hay un manejador de errores local definido en el contexto de ejecución actual.

Funciones ORDA y atributos calculados en 4D Server

Como ya sabrás, cuando una función ORDA o un atributo computado se utiliza en una aplicación cliente, se ejecuta en el lado 4D Server. Por lo tanto, si estas funciones o atributos computados no definen un manejador de errores local y lanzan errores, el diálogo de error incorporado de 4D se muestra en el 4D Server cuando no se ejecuta headless.
Para evitar esto, ahora puede definir un manejador de errores global en el lado del servidor en el método de base de datos On Server Startup por ejemplo:

ON ERR CALL("myServerGlobalErrorHandler"; ek global)

Componentes

Como desarrollador de componentes, ahora es más fácil para usted manejar errores. ¡Sólo tiene que definir su manejador de errores global en el método de base de datos On Host Database Event (por ejemplo, en el evento On before host database startup ) para asegurarse de que ningún error mostrará el diálogo de error incorporado de 4D en la base de datos host! Haciendo esto, todos los errores generados por el componente llamarán al manejador de errores global del componente sin ningún efecto secundario en la base de datos host.

Como usuario de un componente, puede hacer su aplicación más segura manejando los errores del componente que no han sido capturados en el contexto de ejecución del componente. De este modo, si utiliza componentes que no gestionan sus propios errores correctamente, podrá gestionarlos y no aparecerá ningún diálogo de error incorporado en 4D. Para instalar un método manejador de errores de un componente, sólo tiene que utilizar el parámetro correspondiente de esta forma:

ON ERR CALL("myComponentErrorHandler"; ek errors from components)

Este es también un manejador de errores global, pero dedicado a errores no capturados por componentes, de forma que pueda desarrollar cosas específicas para estos. Tenga en cuenta que las variables del sistema de errores(error, método de error, línea de error y fórmula de error) no están disponibles en este gestor de errores de componentes porque los errores provienen de otro contexto de ejecución. Pero la pila de errores sigue estando disponible.

COMPORTAMIENTOS COMUNES

Pila de errores

También hemos introducido un nuevo comando para obtener toda la pila de errores: Last errors. Este comando devuelve una colección en la que cada elemento es un error de toda la pila, cada error contiene información sobre el número de error, el mensaje y la firma interna del componente.

Obtener el gestor de errores actual

El comando Method called on the error admite ahora un parámetro opcional para obtener el gestor de errores global y el gestor de errores del componente, como en este ejemplo:

$localHandler:=Method called on error
$globalHandler:=Method called on error(ek global)
$componentHandler:=Method called on error(ek errors from component)

Abortar error

Independientemente del gestor que se ejecute, el comando ABORT es siempre práctico y permite interrumpir el código como de costumbre.

Puede probar todos estos nuevos comportamientos con el IDH anterior.