Comparteix a través de

Aserciones en el código administrado

  • Article

Una aserción, o instrucción Assert, prueba una condición especificada como un argumento de dicha instrucción Assert. Si la condición se evalúa como true, no se produce ninguna acción. Si la condición se evalúa como false, se produce un error en la aserción. Si está ejecutando una compilación de depuración, el programa entra en modo de interrupción.

En este tema

Aserciones en el espacio de nombres System.Diagnostics

El método Debug.Assert

Efectos secundarios de Debug.Assert

Requisitos de Trace y Debug

Argumentos de Assert

Personalización del comportamiento de Assert

Establecimiento de aserciones en archivos de configuración

Aserciones en el espacio de nombres System.Diagnostics

En Visual Basic y Visual C#, puede utilizar el método Assert de Debug o Trace, que están en el espacio de nombres System.Diagnostics. Los métodos de la clase Debug no se incluyen en una versión de lanzamiento de su programa, de modo que no aumentan el tamaño ni reducen la velocidad de su código de versión.

C++ no admite los métodos de la clase Debug. Se puede conseguir el mismo efecto mediante la clase Trace con compilación condicional, por ejemplo #ifdef DEBUG...#endif.

En este tema

Debug.Assert (Método)

Utilice el método System.Diagnostics.Debug.Assert libremente para probar condiciones que deberían ser true si el código es correcto. Por ejemplo, suponga que ha escrito una función de división de enteros. Según las reglas matemáticas, el divisor nunca puede ser cero. Puede probarlo mediante una aserción:

int IntegerDivide ( int dividend , int divisor )
{
    Debug.Assert ( divisor != 0 );
    return ( dividend / divisor );
}

Cuando se ejecuta este código en el depurador, se evalúa la instrucción de aserción, pero en la versión de lanzamiento no se realiza la comparación, de modo que no se produce sobrecarga adicional.

A continuación se muestra otro ejemplo. Se utiliza una clase que implementa una cuenta corriente, de la siguiente manera:

float balance = savingsAccount.Balance;
Debug.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );

Antes de retirar dinero de la cuenta, desea asegurarse de que hay saldo suficiente para cubrir la cantidad que se dispone a retirar. Puede escribir una aserción para comprobar el saldo:

float balance = savingsAccount.Balance;
Trace.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );

Tenga en cuenta que las llamadas al método System.Diagnostics.Debug.Assert desaparecen cuando se crea una versión de lanzamiento del código. Esto significa que la llamada que comprueba el saldo desaparecerá en la versión de lanzamiento. Para resolver este problema, debe reemplazar System.Diagnostics.Debug.Assert por System.Diagnostics.Trace.Assert, que no desaparece en la versión de lanzamiento:

A diferencia de las llamadas a System.Diagnostics.Trace.Assert, las llamadas a System.Diagnostics.Debug.Assert agregan sobrecarga a la versión de lanzamiento.

En este tema

Efectos secundarios de Debug.Assert

Cuando utilice System.Diagnostics.Debug.Assert, asegúrese de que el código incluido en Assert no cambia el resultado del programa si se quita Assert. De lo contrario, podría producir accidentalmente un error que solo aparezca en la versión de lanzamiento del programa. Preste especial atención a las aserciones que contengan llamadas a funciones o procedimientos, como en el ejemplo siguiente:

// unsafe code
Debug.Assert (meas(i) != 0 );

Este uso de System.Diagnostics.Debug.Assert parece seguro a primera vista, pero suponga que cada vez que se llama a la función meas se actualiza un contador. Cuando se compila la versión de lanzamiento, esta llamada a meas se elimina, de manera que no se actualiza el contador. Este es un ejemplo de una función con efectos secundarios. Cuando se elimina una llamada a una función que tiene efectos secundarios podría producirse un error que solo aparece en la versión de lanzamiento. Para evitar tales problemas, no incluya llamadas a funciones en una instrucción System.Diagnostics.Debug.Assert. En su lugar, utilice una variable temporal:

temp = meas( i );
Debug.Assert ( temp != 0 );

Aunque se utilice System.Diagnostics.Trace.Assert, conviene no colocar llamadas a funciones dentro de una instrucción Assert. Dichas llamadas deben ser seguras, puesto que las instrucciones System.Diagnostics.Trace.Assert no se eliminan en la versión de lanzamiento. No obstante, si se acostumbra a no usar dichas construcciones, la probabilidad de cometer un error al utilizar System.Diagnostics.Debug.Assert será menor.

En este tema

Requisitos de Trace y Debug

Si crea el proyecto mediante los asistentes de Visual Studio, el símbolo TRACE se define de forma predeterminada en las configuraciones de Release y Debug. El símbolo DEBUG se define de forma predeterminada solo en la versión de depuración.

De lo contrario, para que funcionen los métodos Trace, el programa debe tener uno de los siguientes símbolos en la parte superior del archivo de código fuente:

Argumentos de Assert

System.Diagnostics.Trace.Assert y System.Diagnostics.Debug.Assert pueden utilizar hasta tres argumentos. El primer argumento, de uso obligatorio, es la condición que se desea comprobar. Si llama a System.Diagnostics.Trace.Assert(Boolean) o System.Diagnostics.Debug.Assert(Boolean) con un único argumento, el método Assert comprueba la condición y, si el resultado es false, envía el contenido de la pila de llamadas a la Ventana de salida. En el ejemplo siguiente se muestran System.Diagnostics.Trace.Assert(Boolean) y System.Diagnostics.Debug.Assert(Boolean).

Debug.Assert ( stacksize > 0 );
Trace.Assert ( stacksize > 0 );

El segundo y tercer argumento, si existen, deben ser cadenas. Si llama a System.Diagnostics.Trace.Assert o System.Diagnostics.Debug.Assert con dos o tres argumentos, el primer argumento es una condición. El método comprueba la condición y, si el resultado es false, genera la segunda y tercera cadena. En el ejemplo siguiente se muestran System.Diagnostics.Debug.Assert(Boolean, String) y System.Diagnostics.Trace.Assert(Boolean, String) utilizados con dos argumentos:

Debug.Assert ( stacksize > 0, "Out of stack space" );
Trace.Assert ( stacksize > 0, "Out of stack space" );

En el ejemplo siguiente se muestran System.Diagnostics.Debug.Assert(Boolean, String, String) y System.Diagnostics.Trace.Assert(Boolean, String, String) utilizados con tres argumentos:

Debug.Assert ( stacksize > 100, "Out of stack space" , "Failed in inctemp" );
Trace.Assert ( stacksize > 0, "Out of stack space", "Failed in inctemp" );

En este tema

Personalizar el comportamiento de Assert

Si se ejecuta la aplicación en modo de interfaz de usuario, el método Assert muestra el cuadro de diálogo Error de aserción cuando se produce un error en la condición. La propiedad Listeners o Listeners controla las acciones que tienen lugar cuando se produce un error en una aserción.

Puede personalizar el comportamiento del resultado agregando un objeto TraceListener a la colección Listeners, quitar un objeto TraceListener de la colección Listeners o reemplazar el método System.Diagnostics.TraceListener.Fail de un objeto TraceListener existente para que se comporte de forma diferente.

Por ejemplo, podría invalidar el método System.Diagnostics.TraceListener.Fail para escribir en un registro de eventos, en lugar de mostrar el cuadro de diálogo Error de aserción.

Para personalizar el resultado de esta forma, el programa debe contener un agente de escucha, heredar de TraceListener e invalidar su método System.Diagnostics.TraceListener.Fail.

Para más información, vea Agentes de escucha de seguimiento.

En este tema

Establecer aserciones en archivos de configuración

Se pueden establecer aserciones en el archivo de configuración del programa al igual que en el código. Para obtener más información, vea System.Diagnostics.Trace.Assert o System.Diagnostics.Debug.Assert.

Contenido relacionado