El manejo de errores se refiere a los procedimientos de respuesta y recuperación de las condiciones de error presentes en una aplicación de software. Es el proceso que comprende la anticipación, detección y resolución de errores de aplicación, errores de programación o errores de comunicación.
Buenas a todos,
en capítulos anteriores, vimos como "Proteger los datos: Se un mejor cerrajero", en el que explicábamos como proteger nuestros recursos aplicando un control extra al acceso mediante OAUTH2 que nos ofrece Intersystems. Y como no hay 2 sin 3, aquí tenemos un tercer articulo, en el cual vamos a explicar como "avisar a la policía" de que alguien malicioso está intentando acceder a nuestros datos.
Podéis encontrar errores en cualquier punto de la ejecución del programa, y hay varias formas de generarlos y manejarlos en IRIS. En este artículo, exploraremos cómo gestionar excepciones de manera eficiente.
Uno de los tipos de retorno más utilizados es %Status, que los métodos emplean para indicar éxito o fallo. Vamos a empezar hablando de los valores de %Status.
Si tenéis tablas de sistema que implementan la funcionalidad "VERSIONPROPERTY", podéis encontraros con el error 5800. Este artículo explica cómo se produce este error y proporciona soluciones para resolver el problema.
Cuando se implementa la comprobación de versiones, la propiedad especificada por VERSIONPROPERTY se incrementa automáticamente cada vez que se actualiza una instancia de la clase (ya sea mediante objetos o SQL).
Por ejemplo:
¡Hola amigos!
No es una innovación, pero a menudo veo páginas de error de aplicaciones CSP que no son demasiado informativas. Algo de este estilo:
Si resuelves problemas complejos en ObjectScript, probablemente tienes mucho código que funciona con los valores de %Status. Si has interactuado con clases persistentes desde una perspectiva de objetos (%Save, %OpenId, etc.), casi seguro que las ha visto.
Un %Status proporciona una envoltura alrededor de un mensaje de error localizable en las plataformas de InterSystems. Un estado OK ($$$OK) simplemente es igual a 1, mientras que un mal estado ($$$ERROR(errorcode,arguments...)) se representa como un 0 seguido de un espacio seguido de una lista $ListBuild con información estructurada sobre el error.
Hola a todos,
Tengo una regla para lanzar un mensaje cuando hay un error. Quiero evitar enviar el correo si el origen del error es la API para enviar el correo
Esta es mi regla:
Ahora, si hay algún error en algún proceso, funciona, pero si hay un error en MyProduct.BO.SendEmail está intentando enviar el error nuevamente, y es un bucle infinito.
¿Hay alguna forma para verificar cuál es el origen y no procesar si el origen es MyProduct.BO.SendEmail?
Intenté establecer una condición en el nodo when pero no detecta ninguna propiedad de Ens.AlertRequest
Algunos de vosotros no conoceréis esta limitación o problema conocido que se produce en los Procesos de Negocio (Business Processes) basados en BPL.
Aquellos que no estabais al tanto quizá os habéis encontrado esto:
ERROR <Ens>ErrBPTerminated: Terminating BP <my_process_name> # due to error:
ERROR #7201: Datatype value 'xxS6xxS6...xxS6' length longer than MAXLEN allowed of 5
Una unidad de código en ObjectScript (pongamos, un ClassMethod) puede producir una gran variedad de efectos secundarios inesperados cuando interactúa con partes del sistema que están fuera de su propio alcance y no han sido depuradas adecuadamente. En forma de lista parcial, se incluyen:
Hola a todos! Os traigo hoy un ejemplo de código que compartía Robert Cemper para mostrar por SQL los registros de error almacenados en ^ERRORS.
¡Hola, desarrolladores!
Como sabeis, los errores de la aplicación están en el global ^ERRORS. Aparecen si los llamas:
d e.Log() en la sección Catch de Try-Catch.
Con la propuesta de @Robert Cemper, ahora se puede utilizar SQL para examinarlo.
Inspirado por el módulo de Robert, presenté un módulo simple de IRIS Analytics que muestra estos errores en un dashboard:
