Hola compañeros, Saludos a todos, y Gracias por las ideas que me han dado muy amablemente.

Esta vez me asalta esta inquietud:

Necesito crear un modulo que me capture los errores que puedan suceder en mi aplicación, pero a nivel global no procedual pues conozco de las sentencias:

TRY  Ejemplo:





El los contenedoresForm(qb.qt) no veo un evento ONERROR  o ERROR donde pueda GOLBALMENTE intersertarlos.

Al lograrlo también me gustaría recibir:

1. El nombre del Procedimiento donde se produjo el error
2. La linea de código donde se produjo

Gracias por la Guía que me puedan dar.

PD:

Recuerden Intersertar errores GLOBAL que se pueda producir en cualquier Procedimiento/Función de toda la aplicación, y NO escritura LOCAL en Lineas o Bloques en Procedimientos.

Interesante. Pero mi experiencia intentando algo parecido no tuvo éxito en su momento...

Pensé que la clase Error (no ERROR en mayúsculas) la podía usar para lo que dices pasando el valor de sus propiedades a un formulario diseñado al efecto:

En un procedimiento cualquiera:



Y en el form "FormError":



Pero no funciona. Según Benoît, porque la clase Error es virtual y sus valores se pierden nada más salir del procedimiento que los genera.

Hasta ahora no he encontrado la forma de solucionarlo ni tampoco él me ha indicado cómo, si es que es posible.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Un tema interesante.

A ver como sale esto:

Me creo una clase ClaseError con el siguiente contenido:

Citar:

inherits error

Ahora en un módulo de la aplicacion marcado como clase de inicio hago lo siguiente


Ahora en cada formulario o clase  debería haber una única función para tratar el error. Es muy cierto lo que dice JGuardón. El error persiste en el formulario o clase pero luego muere. Lo que pasa es que el error puede propagarse dentro del formulario o clase.

Osea que si yo tengo una función que tiene un catch y un finally y en esa función llamo a otra función que no lo tiene y esta  llama a otra función que tampoco lo tiene (una función nieto) y en esta ocurre el error lo que ocurriŕa es que el error se propagará y saltará en el catch inicial.

Osea que si yo programo ese catch inicial debería valer.
Este debería se el catch


En la clse ClaseError podríamos crear propiedades adicionales o métodos apropiados para el tratamiento de ese error según queramos.
El catch y el finaly por tanto deberían ir en alguna función de tipo superior. No puedo probar ahora pero la cosa sería que al ocurrir un error en alguna función que no tiene tratamiento de error salte a la función padre o abuelo o lo que sea. El error terminará cuando corresponda pero la clase ErrorClase que contiene toda la información persistirá.

Creo que eso o algo muy parecido deberia funcionarl

El problema que le veo a este planteamiento es que los errores no persisten en formularios o clases, sino que se propagan únicamente de la rutina que fue llamada a la rutina que la llamó (y esto puede darse en varios niveles de anidamiento), pero no es común ni acertado escribir código que tenga un anidamiento de ese tipo (una rutina que llama a otra, que a la vez llama a una tercera, que llama a una cuarta...)

Aún si alguien escribe su código de ese modo la rutinas que no fueran parte de esos anidamientos no estarían cubiertas.

Para que la idea funcione debería escribirse una clase de inicio (o módulo) que incluya un método puente y una interfaz de métodos públicos que llaman al método puente. Éste a su vez deberá llamar al método privado que correponda (interfaz de métodos privados). El método puente debe contener la sentencia CATH que trata los errores (directamente o través de otro método).

Ejemplo:




Esto no lo he probado sólo es una deducción lógica que espero sea acertada.

Saludos cordiales.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Bueno, una cosa es que se pueda hacer que por poder parece que se puede y aquí se han expuesto algunas ideas, pero no creo que sae una buena idea (aunque yo no tengo el patrimonio de la razón obviamente).

Quizá mejor solución es crear una clase con un formulario y algunas propiedades para que en caso de error (en los catch respectivos) se haga una llamada a esa clase y se informe el error o se haga alguna cosa. En mi opinión es suficiente con el message, pero creo que ese tipo de cosas a la larga dan mas problemas que otra cosa. En mi opinión cada rutina debe llevar su propio control de errores, pero solo es una opinión claro.

 

Citar:

En mi opinión cada rutina debe llevar su propio control de errores, pero solo es una opinión claro.

Comparto esa opinión. Sólo que en un programa hay rutinas que realmente no necesitan capturar posibles errores (las que son extremadamente simples) o aquellas en las que puede evitarse la posibilidad de error por ejemplo:

Claramente, una única rutina de tratamiento de errores para toda una clase (que fácilmente puede contener más que unos pocos métodos) sería demasiado extensa o compleja. De modo que las rutinas que lo necesiten deberían tener su propio código para manejar sus errores.

Una aclaración más. Hay errores no tienen por qué ser informados al usuario (hacerlo incluso podría significar un problema de seguridad), especialmente aquellos que la aplicación puede solventar sin intervención del usuario o aquellos que desde el principio conocemos que el usuario no podrá resolver.

===================
Cómo programar con Gambas

Speed Books: informática libre.