Compartir a través de

Excepciones y rendimiento

Nota:

Este contenido se reimprime con permiso de Pearson Education, Inc. de Directrices de diseño de frameworks: Convenciones, expresiones y patrones para bibliotecas reutilizables de .NET, 2ª edición. Esa edición fue publicada en 2008, y el libro ha sido totalmente revisado en la tercera edición. Parte de la información de esta página puede estar obsoleta.

Una preocupación común relacionada con las excepciones es que, si se usan excepciones para el código que se produce un error rutinario, el rendimiento de la implementación será inaceptable. Tiene sentido que exista esta preocupación. Cuando un miembro genera una excepción, su rendimiento puede ser más lento. Sin embargo, es posible lograr un buen rendimiento al tiempo que se adhiere estrictamente a las directrices de excepción que no permiten usar códigos de error. Dos patrones descritos en esta sección sugieren maneras de hacerlo.

❌ NO use códigos de error debido a preocupaciones de que las excepciones puedan afectar negativamente al rendimiento.

Para mejorar el rendimiento, es posible usar el patrón de Tester-Doer o el patrón de Try-Parse, que se describe en las dos secciones siguientes.

Patrón tester-doer

A veces, el rendimiento de un miembro de generación de excepciones se puede mejorar dividiéndolo en dos. Echemos un vistazo al método Add de la interfaz ICollection<T>.

ICollection<int> numbers = ...
numbers.Add(1);

El método Add se inicia si la colección es de solo lectura. Esto puede ser un problema de rendimiento en escenarios en los que se espera que se produzca un error en la llamada al método a menudo. Una de las formas de mitigar el problema es probar si la colección se puede escribir antes de intentar agregar un valor.

ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
    numbers.Add(1);
}

El miembro usado para probar una condición, que en nuestro ejemplo es la propiedad IsReadOnly, se conoce como evaluador. Al miembro que se utiliza para realizar una operación potencialmente generadora de excepciones, el método Add en nuestro ejemplo, se le conoce como "doer".

✔️ CONSIDERE usar el patrón Tester-Doer para los miembros que podrían lanzar excepciones en escenarios comunes y así evitar problemas de rendimiento relacionados con las excepciones.

Patrón try-parse

Para las API extremadamente sensibles al rendimiento, se debe usar un patrón aún más rápido que el patrón de Tester-Doer descrito en la sección anterior. El patrón realiza llamadas para ajustar el nombre de los miembros con el fin de convertir un caso de prueba bien definido en una parte de la semántica de los miembros. Por ejemplo, DateTime define un Parse método que produce una excepción si se produce un error en el análisis de una cadena. También define un método correspondiente TryParse que intenta analizar, pero devuelve false si el análisis no es correcto y devuelve el resultado de un análisis correcto mediante un out parámetro .

public struct DateTime
{
    public static DateTime Parse(string dateTime)
    {
        ...
    }
    public static bool TryParse(string dateTime, out DateTime result)
    {
        ...
    }
}

Al usar este patrón, es importante definir la funcionalidad try en términos estrictos. Si el miembro falla por cualquier motivo distinto de un intento bien definido, el miembro todavía debe lanzar una excepción correspondiente.

✔️ Recomendamos el patrón try-parse para los miembros que podrían generar excepciones en escenarios comunes para evitar problemas de rendimiento relacionados con las excepciones.

✔️ Use el prefijo "try" y el tipo de valor devuelto booleano para los métodos que implementan este patrón.

✔️ Proporcione un miembro de generación de excepciones para cada miembro mediante el patrón try-parse.

© Partes 2005, 2009 de Microsoft Corporation. Todos los derechos reservados.

Reimpreso con permiso de Pearson Education, Inc. de Framework Design Guidelines: Convenciones, Idiomas y Patrones para Bibliotecas .NET Reusables, 2ª Edición por Krzysztof Cwalina y Brad Abrams, publicado el 22 de octubre de 2008 por Addison-Wesley Professional como parte de la Serie Desarrollo de Microsoft Windows.

Consulte también

  • Last updated on