C++ Try Catch

[Schaffer]

 A ver, una pequeña duda que me corroe, me gustaria saber que usais en vuestros programas en C++ para un control de errores de ejecucion adecuado.

Y mas en particular, si usais try y catch en C++ y lo eficiente que es respecto a la velocidad de ejecucion.

Vamos, que si esto es mejor que comprobar que el segundo operando no es 0 en cada division:

Código [Seleccionar] Expand


class DivisionPorCero
{
 public:
 double divisor;
 DivisionPorCero(double x);
};

DivisionPorCero::DivisionPorCero(double x) : divisor(x)
{}
int dividir(int x, int y)
{
 if(y==0)
   throw DivisionPorCero(x);
}

try
{
 dividir(12, 0);
}
catch (DivisionPorCero divCero)
{
 cerr<<"Intentando dividir "<<divCero.divisor<<" por cero";
}



Gracias por adelantado a los que contesten. (Al resto no)

[synchrnzr]

 No hay mucha diferencia en cuanto a eficiencia de usar try()/catch() a usar un if(), de hecho acostumbra a ser menos eficiente. La diferencia/ventaja principal es que si no se puede tratar la excepción en el nivel de ejecución acutal, se propaga a niveles superiores.

En cuanto a mejorar la eficiencia del código, mírate un poco el tema de la programación por contrato. Comprobar cada vez que vas a hacer una división si el divisor es 0 desde luego no es muy óptimo. A un nivel tan bajo yo no haría ninguna comprobación, la dejaría como precondición para el nivel superior.

Un ejemplo rapidillo:

- El usuario introduce un número en un cuadro de texto. El cuadro está configurado para que el usuario no pueda introducir valores menores que cero.
- El valor que ha introducido es un parámetro de un algoritmo que no puede ser menor que cero para que el algoritmo funcione. Comprobamos que no es menor que cero para llamar a la función del algoritmo.
- El algoritmo comprueba que todos los parámetros son correctos (es decir, si ese valor es mayor que 0 o no) y si son correctos tira p'alante.
- El algoritmo utiliza el valor en una división. En la división compruebas que es mayor que 0 antes que dividir.

La programación por contrato, básicamente lo que intenta es evitar situaciones como esta. Es decir: ¿en el cuadro de texto ya compruebas que el número sea positivo? Pues a la hora de diseñar las demás funciones, simplemente supones que el valor es positivo y no tienes que comprobar nada. Eso sí, para que las funciones chuten, es necesario que el valor ese sea positivo. A eso se le llama precondición.

Toma, te dejo este enlace por si quieres ampliar conocimientos sobre ingeniería del soft :)

sync

[Zaelsius]

 Las precondiciones y postcondiciones se suelen marcar a veces mediante asertos.

La macro "assert" de C++(en ) cumple este cometido. Un ejemplillo:

Código [Seleccionar] Expand


int dividir(int x, int y)
{
 assert(y);         // equivale a assert(y!=0)
 DivisionPorCero(x);
}


O imagina que tienes una función "RaízCuadrada":

Código [Seleccionar] Expand


int RaizCuadrada(int x)
{
int tmp = CalculaRaiz(x);
assert(tmp>=0); // si el valor es negativo significa que algo falló en
                           // CalculaRaiz
return tmp;
}



Assert es una macro que sólo se expande en modo de depuración, y lanzará un error visible por el usuario y por el depurador si la condición impuesta no se cumple.

[synchrnzr]

 Muy cierto lo que dice ZaelSius (menudo rollo le he soltado para olvidarme de comentarle el tema (nooo)) En fin... por lo menos ya ha pasado el viernes y sigo vivo... (ole)

sync

[Mars Attacks]

 Me alegro por ti, sync.

De todas formas, ¿para qué te preocupas por la eficiencia en un programa cuyo tiempo de respuesta va a ser un 99'99% dependiente del humano? Si es algo que debieras calcular 30 veces por segundo lo entiendo, pero ese ejemplo...

En mi opinión, no está de más recomprobar las condiciones a bajo nivel (porque todos sabemos que luego pasa lo que pasa y más vale prevenir).

[Schaffer]

 Vale, mal ejemplo, mea culpa. Bueno, aun asi Mars, si que puede interesar la velocidad cuando lees de un fichero, pero no era eso lo que queria preguntar. Por cierto, muy interesante lo del assert, no tenia ni idea de que existiera   :P .

Pues eso, que lo que me interesaba es saber, en el ambito de los graficos en tiempo real, como comprobais y controlais los errores del tipo el archivo no esta o cualquier error gordo, y si usais la tecnica OpenGL de guardaros los errores, a la espera de que el programa los pida o usais excepciones por todas partes en plan Java.

Gracias y espero haberme explicado mejor ahora.

Toma, te dejo este enlace por si quieres ampliar conocimientos sobre ingeniería del soft  :)

Gracias, pero ya tuve bastante el año pasado con la asignatura de ese nombre.
Aqui podeis ver una de las paginas mas feas que he visto en mi vida, que por cierto es la de mi profesor de IS.

[AgeR]

Pues eso, que lo que me interesaba es saber, en el ambito de los graficos en tiempo real, como comprobais y controlais los errores del tipo el archivo no esta o cualquier error gordo, y si usais la tecnica OpenGL de guardaros los errores, a la espera de que el programa los pida o usais excepciones por todas partes en plan Java.

Bueno, aunque no soy ningún ejemplo a seguir, yo suelo compilar en release y usar logs para controlar todo este tipo de incidencias  :ph34r:

PD: Caramba, otro ujiano en stratos!  (uoh)  

[MChiz]

 Asserts al poder!!! :bb Y los try y catch tambien! Yo sinceramente recomiendo ambos, y sobretodo un uso intensivo de asserts. Anda que no me han ayudado a ahorrar horas y horas de trabajo...