Información general sobre el rendimiento

Actualización: noviembre 2007

El rendimiento puede ser un factor clave de un sitio o proyecto web correcto. Este tema proporciona instrucciones para mejorar el rendimiento de un sitio, así como vínculos a la documentación de procedimientos recomendados.

Este tema contiene:

Procedimientos recomendados
Información general
Ejemplos de código

Procedimientos recomendados

La lista siguiente proporciona vínculos a recursos en el sitio web de Microsoft que describen procedimientos recomendados generales para mejorar el rendimiento de un sitio de web ASP.NET.

Volver al principio

Información general

La sección enumera las técnicas que puede utilizar para maximizar el rendimiento de las aplicaciones web ASP.NET. Las instrucciones se dividen en las secciones siguientes:

Procesamiento de páginas y controles de servidor
Administración del estado
Acceso a datos
Aplicaciones Web
Prácticas de codificación

Procesamiento de páginas y controles de servidor

Las instrucciones siguientes sugieren formas de trabajar eficazmente con páginas y controles ASP.NET.

Evite los viajes de ida y vuelta (round trips) innecesarios al servidor En algunas situaciones, puede utilizar ASP.NET AJAX y la representación parcial de la página para realizar tareas en el código del explorador sin efectuar una devolución (postback) completa. Por ejemplo, puede utilizar las características de ASP.NET AJAX para validar los datos proporcionados por el usuario en el explorador antes de que se envíen al servidor. Para obtener más información, vea Información general sobre AJAX en ASP.NET y Información general sobre la representación parcial de páginas.
Por lo general, si no tiene que retransmitir información al servidor para comprobarla o escribirla en un almacén de datos, puede mejorar el rendimiento de la página (y por consiguiente la experiencia del usuario) si evita los viajes de ida y vuelta (roundtrips) al servidor.
Si desarrolla controles de servidor personalizados, considere la posibilidad de diseñarlos para representar el script de cliente para alguna de sus funcionalidades. Esto puede reducir significativamente el número de veces que se envía información al servidor web. Para obtener más información, vea Desarrollar controles de servidor ASP.NET personalizados y Crear script de cliente personalizado mediante el uso de Microsoft AJAX Library.
Utilice la propiedad IsPostBack del objeto Page para evitar procesamientos innecesarios Evite ejecutar el código en cada devolución (postback) si solamente tiene que ejecutarlo la primera vez que se solicite la página. Puede probar la propiedad IsPostBack para ejecutar el código condicionalmente en función de si la página se ejecuta en respuesta a un evento de control de servidor.
Mantenga el almacenamiento en búfer activado a menos que tenga razones para desactivarlo Deshabilitar el almacenamiento en búfer de las páginas Web ASP.NET representa un costo de rendimiento significativo. Para obtener más información, vea la propiedad Buffer.
Utilice el método Transfer del objeto Server o use la publicación en varias páginas para redirigir entre páginas ASP.NET en la misma aplicación Para obtener más información, vea Redirigir a los usuarios a otra página.

Administración de estado

En las instrucciones siguientes encontrará sugerencias para que la administración de estado sea eficaz.

Guarde el estado de vista del control de servidor solo cuando sea necesario El estado de vista permite que los controles de servidor vuelvan a rellenar los valores de sus propiedades en un viaje de ida y vuelta (round trip) sin que sea necesario escribir código. Sin embargo, el estado de vista afecta al rendimiento y tamaño de la página porque se transmite al y desde el servidor en un campo de formulario oculto. Si va a enlazar un control de servidor a datos en cada viaje de ida y vuelta (round trip), el estado de vista guardado no es útil, porque los valores del control se reemplazan con nuevos valores durante el enlace de datos. En ese caso, si deshabilita el estado de vista, reducirá el tiempo de procesamiento y el tamaño de la página.

De forma predeterminada, el estado de vista está habilitado para todos los controles de servidor. Para deshabilitarlo para un control, establezca la propiedad EnableViewState del control en false, como en el ejemplo siguiente:
```
<asp:datagrid EnableViewState="false" datasource="..." 
   />
```
También puede deshabilitar el estado de vista de una página utilizando la directiva @ Page, como se muestra en el ejemplo siguiente:
```
<%@ Page EnableViewState="false" %>
```
Esto resulta útil cuando la página no requiere el procesamiento de la devolución (postback).

Nota:

El atributo EnableViewState también se admite en la directiva @ Control para especificar si el estado de vista se habilita para un control de usuario.

Para analizar el tamaño del estado de vista de una página, habilite la traza de la página estableciendo en trace="true" la directiva @ Page. En el resultado de la traza, examine la columna Viewstate de la tabla Control Hierarchy. Para obtener más información, vea Información general sobre el seguimiento en ASP.NET.
Evite utilizar el cifrado del estado de vista a menos que sea necesario El cifrado del estado de vista impide que los usuarios puedan leer los valores en el campo de estado de vista oculto. Por ejemplo, podría cifrar el estado de vista si una página incluye un control GridView que mantiene un campo de identificador en la propiedad DataKeyNames para coordinar las actualizaciones con los registros. Dado que no desea que el identificador esté visible para los usuarios, puede cifrar el estado de vista. Sin embargo, el cifrado tiene un costo constante para el rendimiento de la inicialización, así como un costo adicional que depende del tamaño del estado de vista que se cifre. El cifrado se realiza cada vez que se carga la página. Por consiguiente, se produce el mismo efecto en el rendimiento la primera vez que se solicita la página y durante cada devolución (postback).
Deshabilite el estado de sesión cuando no lo utilice Para deshabilitar el estado de sesión de una página, establezca el atributo EnableSessionState de la directiva @ Page en false, como en el ejemplo siguiente:
```
<%@ Page EnableSessionState="false" %>
```
Nota:

Si una página requiere acceso a las variables de sesión pero no va a crearlas ni modificarlas, establezca el atributo EnableSessionState de la directiva @ Page en ReadOnly.

También puede deshabilitar el estado de sesión de los métodos de servicio web ASP.NET. Para obtener más información, vea Información general sobre los servicios de aplicación ASP.NET.

Para deshabilitar el estado de sesión para una aplicación, establezca el atributo Mode en Off en la sección SessionState del archivo Web.config de la aplicación, como en el ejemplo siguiente:
```
<sessionState mode="Off" />
```
Elija el proveedor del estado de sesión adecuado para su aplicación ASP.NET proporciona varias maneras de almacenar los datos de la sesión de la aplicación. Estos incluyen el estado de sesión en proceso, estado de sesión fuera de proceso como un servicio de Windows y estado de sesión fuera de proceso en una base de datos de SQL Server. (También puede crear un proveedor de estado de sesión personalizado para almacenar los datos de sesión en un almacén de datos que especifique). Cada enfoque tiene sus ventajas, pero el estado de sesión en proceso es, con diferencia, el enfoque más rápido. Si únicamente utiliza el estado de sesión para cantidades de datos pequeñas en el estado de sesión, utilice el proveedor en proceso. Utilice las opciones de estado de sesión fuera de proceso si escala la aplicación en varios procesadores o varios equipos, o si desea conservar los datos de la sesión cuando se reinicie un servidor o proceso. Para obtener más información, vea Información general sobre el estado de sesión de ASP.NET.

Nota:
El atributo EnableViewState también se admite en la directiva @ Control para especificar si el estado de vista se habilita para un control de usuario.

Nota:
Si una página requiere acceso a las variables de sesión pero no va a crearlas ni modificarlas, establezca el atributo EnableSessionState de la directiva @ Page en ReadOnly.

Acceso a datos

En las instrucciones siguientes se ofrecen sugerencias para que el acceso a los datos en la aplicación sea eficaz.

Use SQL Server y procedimientos almacenados para el acceso a los datos SQL Server es la opción recomendada en cuanto al almacenamiento de datos para crear aplicaciones web escalables y de alto rendimiento. Si utiliza el proveedor SQL Server administrado, el rendimiento mejorará aún más si emplea, siempre que sea posible, procedimientos almacenados compilados en lugar de comandos SQL. Para obtener más información, vea Configurar parámetros y tipos de datos de parámetros (ADO.NET).
Utilice la clase SqlDataReader para los cursores de datos de solo avance rápido La clase SqlDataReader crea una secuencia de datos de solo avance y solo lectura que se recupera de una base de datos de SQL Server. La clase SqlDataReader utiliza el formato de transferencia de datos de red nativo de SQL Server para leer los datos directamente de una conexión de base de datos. Si lo encuentra práctico, utilice la clase SqlDataReader, porque proporciona un mejor rendimiento que la clase DataSet. Por ejemplo, al enlazar un control de datos al control SqlDataSource, logrará un mejor rendimiento si establece la propiedad DataSourceMode en DataReader. (Sin embargo, un lector de datos admite menos funcionalidad que el modo DataSet). La clase SqlDataReader implementa la interfaz IEnumerable, que permite enlazarle controles de servidor. Para obtener más información, vea la clase SqlDataReader y Obtener acceso a datos con ASP.NET.
Almacene en caché los datos y resultados de la página siempre que sea posible Use el almacenamiento en caché ASP.NET si las páginas o los datos no tienen que calcularse dinámicamente para cada solicitud de página. Si es posible, diseñe páginas y solicitudes de datos para que se almacenen en la memoria caché, sobre todo para las situaciones en la que espere mucho tráfico. Si utiliza la memoria caché correctamente, puede mejorar el rendimiento del sitio más que si utiliza cualquier otra característica de .NET Framework.

Al utilizar el almacenamiento en caché de ASP.NET, siga estas instrucciones. Primero, no almacene en memoria caché demasiados elementos, porque cada elemento almacenado en caché requiere memoria del servidor. Por ejemplo, no almacene en memoria caché los elementos que se actualizan con facilidad o se utilizan raramente. En segundo lugar, no asigne un período de expiración corto a los elementos almacenados en caché. Los elementos que expiran rápidamente pueden suponer un trabajo adicional para el código de limpieza y para el recolector de elementos no utilizados. Puede supervisar la renovación de la memoria caché causada por la expiración de elementos mediante el contador de rendimiento Tasa de renovación total de caché que está asociado al objeto de rendimiento Aplicaciones ASP.NET. Una tasa alta de renovación puede indicar la existencia de un problema, especialmente si los elementos se quitan antes de que expiren. (Esta situación en ocasiones se denomina necesidad de memoria.)

Para obtener información sobre cómo almacenar en caché los resultados de página y las solicitudes de datos, vea Información general sobre el almacenamiento en caché en ASP.NET.
Utilice la dependencia de caché de SQL de manera apropiada Para almacenar en caché datos de SQL Server, ASP.NET admite el sondeo basado en tabla y la notificación de consulta, según la versión de SQL Server que se utilice. Todas las versiones de SQL Server admiten el sondeo basado en tabla. En el sondeo basado en tabla, si cambia algún dato de una tabla, se invalidan todos los elementos de caché que dependen de la tabla. Esto puede generar una renovación de código innecesaria en la memoria caché. El sondeo basado en tabla no es recomendable para las tablas que cambian con gran frecuencia. Por ejemplo, el sondeo basado en tabla sería recomendable para una tabla de catálogos, que no cambia con frecuencia. No se recomendaría para una tabla de pedidos que se actualiza con frecuencia.

SQL Server 2005 y las versiones posteriores admiten la notificación de consultas. La notificación de consultas utiliza las consultas SQL para detectar cambios en un conjunto concreto de filas. Esto reduce el número de notificaciones que se envían cuando cambia una tabla. La notificación de consultas puede proporcionar mejor rendimiento que el sondeo basado en tabla. Sin embargo, no llega a miles de consultas.

Para obtener más información acerca de la dependencia de caché de SQL, vea Tutorial: Utilizar el almacenamiento en la caché de resultados de ASP.NET con SQL Server y Almacenar en caché en ASP.NET con la clase SqlCacheDependency.
**Utilice la paginación y ordenación del origen de datos en lugar de la paginación y ordenación de la interfaz de usuario **La característica de paginación de interfaz de usuario de los controles de datos como DetailsView y GridView puede utilizarse con cualquier objeto de origen de datos que admita la interfaz ICollection. Para cada operación de paginación, el control de datos pide al origen de datos toda la recolección de datos, selecciona las filas que se van a mostrar y descarta los datos restantes.

Si un control de origen de datos implementa DataSourceView y la propiedad CanPage devuelve true, el control de datos utilizará la paginación de origen de datos en lugar de la paginación de interfaz de usuario. En ese caso, el control de datos solicita solo las filas necesarias para cada página que se va a mostrar. Por consiguiente, la paginación de origen de datos resulta más eficaz que la paginación de interfaz de usuario. Entre los controles ASP.NET estándar, solo el control de origen de datos ObjectDataSource y LinqDataSource admiten la paginación de origen de datos. Para habilitar la paginación de origen de datos para otros controles de origen de datos, puede heredar del control de origen de datos que desea utilizar y, a continuación, modificar su comportamiento.
**Utilice una columna de marca de tiempo para el control de simultaneidad con el control LinqDataSource **Si una tabla de base de datos de SQL Server no contiene una columna Timestamp (un tipo de datos de SQL Server), el control LinqDataSource comprueba la simultaneidad de los datos almacenando los valores de los datos originales en la página web. LINQ to SQL comprueba los valores originales en la base de datos antes de actualizar o eliminar los datos. Este enfoque puede crear una página web de gran tamaño si el registro de datos contiene muchas columnas o valores de columna grandes. También puede representar un riesgo para la seguridad si el registro contiene datos que no desea exponer en la página. Cuando una tabla de base de datos tiene una columna Timestamp, el control LinqDataSource almacena solo el valor de marca de tiempo para futuras comparaciones. LINQ to SQL puede comprobar la coherencia de los datos determinando si la marca de tiempo original coincide con el valor de marca de tiempo actual de la tabla. Para obtener más información acerca de las marcas de tiempo, vea timestamp (Transact-SQL) en el sitio web de MSDN.

Sopese la ventaja de la validación de eventos en términos de seguridad y su costo para el rendimiento Los controles que se deriven de las clases System.Web.UI.WebControls y System.Web.UI.HtmlControls pueden validar que un evento originado desde la interfaz de usuario es representado por el control. Esto ayuda a evitar que el control responda a una notificación de eventos suplantada. Por ejemplo, utilizando la validación de eventos, el control DetailsView puede evitar que un usuario malintencionado haga a una llamada a Delete (que no se admite inherentemente en el control) y manipula el control para eliminar los datos. La validación de eventos afecta al rendimiento. Puede controlar la validación de eventos mediante el elemento de configuración EnableEventValidation y el método RegisterForEventValidation. El costo de validación depende del número de controles en la página y tiene un intervalo de unos porcentajes.

Nota de seguridad:
Se recomienda no deshabilitar la validación de eventos. Antes de deshabilitar la validación de eventos, asegúrese de que no se pudo construir ninguna devolución (postback) que pueda tener un efecto imprevisto en la aplicación.

**Utilice el almacenamiento en caché, la ordenación y el filtrado del control SqlDataSource **Si la propiedad DataSourceMode del control SqlDataSource está establecida en DataSet, el control SqlDataSource puede almacenar en caché el conjunto de resultados de una consulta. Las operaciones de filtrado y ordenación del control SqlDataSource pueden utilizar a continuación los datos almacenados en la memoria caché. Una aplicación se puede ejecutar más rápidamente si almacena en memoria caché todo el conjunto de datos y utiliza las propiedades SortParameterName y FilterExpression para ordenar y filtrar. A continuación, el control de origen de datos puede evitar que se realicen consultas SQL con las cláusulas Where y Sort By para obtener acceso a la base de datos cada vez que los usuarios ordenen o filtren datos en la interfaz de usuario.

Aplicaciones Web

En las instrucciones siguientes se ofrecen sugerencias para que el conjunto de aplicaciones web funcione eficazmente.

Precompile el sitio Una aplicación web se compila por lotes en la primera solicitud de un recurso, por ejemplo una página web ASP.NET. Si no se ha compilado ninguna página de la aplicación, la compilación por lotes compila todas las páginas de un directorio en fragmentos para mejorar el uso del disco y de la memoria. Puede utilizar la Herramienta de compilación de ASP.NET (Aspnet_compiler.exe) para precompilar una aplicación web. Para la compilación en contexto, la herramienta de compilación llama al motor en tiempo de ejecución de ASP.NET para que compile el sitio de la misma manera que cuando un usuario solicita una página del sitio web. Puede precompilar una aplicación Web para que se conserve el marcado de UI o puede precompilar las páginas para que no se pueda cambiar el código fuente. Para obtener más información, vea Cómo: Precompilar sitios Web ASP.NET.
Deshabilite el modo de depuración Deshabilite siempre el modo de depuración antes de implementar una aplicación de producción o realizar cualquier medida del rendimiento. Si el modo de depuración está habilitado, el rendimiento de la aplicación puede disminuir. Para obtener más información acerca del modo de depuración, vea Editar los archivos de configuración de ASP.NET.
Ajuste los archivos de configuración para el equipo del servidor web y para aplicaciones concretas La configuración predeterminada de ASP.NET habilita el conjunto de características más amplio y los escenarios más comunes. Puede cambiar algunos valores de la configuración predeterminada para mejorar el rendimiento de las aplicaciones, dependiendo de las características que utilice. La lista siguiente incluye cambios de configuración que debería considerar:
- Habilite la autenticación solo para las aplicaciones que la necesiten De manera predeterminada, el modo de autenticación de las aplicaciones ASP.NET es la autenticación de Windows o NTLM integrada. En la mayoría de los casos conviene deshabilitar la autenticación en el archivo Machine.config y habilitarla en los archivos Web.config de las aplicaciones que la necesiten.
- Configure la aplicación de forma que utilice los valores de codificación de solicitudes y respuestas adecuados La codificación predeterminada de ASP.NET es UTF-8. Si la aplicación utiliza únicamente caracteres ASCII, configúrela para ASCII y obtendrá una ligera mejora del rendimiento.
- Deshabilite AutoEventWireup para la aplicación Si se establece el atributo AutoEventWireup en false en el archivo Web.config, se evita que la página enlace los eventos de página a los métodos basándose en la coincidencia de nombres (por ejemplo, Page_Load). Esto produce una pequeña mejora del rendimiento de las páginas. Para controlar los eventos de página, utilice una de estas dos estrategias. La primera estrategia es invalidar los métodos. Por ejemplo, puede invalidar el método OnLoad del objeto Page para escribir código para el evento de carga de página. (Asegúrese de que llama al método base para comprobar que se provocan todos los eventos). La segunda estrategia consiste en enlazar a los eventos de página mediante la palabra clave Handles en Visual Basic o la conexión automática en C#.
- Quite los módulos no utilizados de la canalización de procesamiento de solicitudes De manera predeterminada, todas las características se mantienen activas en el nodo HttpModules del archivo Machine.config del servidor web. Dependiendo de las características utilizadas en la aplicación, puede quitar los módulos que no se utilicen de la canalización de solicitudes con el fin de obtener una ligera mejora del rendimiento. Revise cada módulo y su funcionalidad y personalícelo para adaptarlo a sus necesidades. Por ejemplo, si no utiliza el estado de sesión ni el almacenamiento en la memoria caché de resultados en la aplicación, puede quitar los módulos de estas características de la lista HttpModules.
Ejecute las aplicaciones web fuera de proceso en Internet Information Services 5.0. De manera predeterminada, ASP.NET en IIS 5.0 atenderá las solicitudes mediante un proceso de trabajo fuera de proceso. Esta característica se ha ajustado para un mayor rendimiento. Debido a sus características y ventajas, se recomienda ejecutar ASP.NET en un proceso de trabajo fuera de proceso para sitios de producción.
Recicle los procesos periódicamente. Los procesos deben reciclarse periódicamente, tanto por motivos de estabilidad como por motivos de rendimiento. A largo plazo, los recursos con errores y pérdidas de memoria pueden afectar al rendimiento del servidor Web y el reciclaje de los procesos evita que la memoria tenga este tipo de problemas. Sin embargo, debería pensar si es necesario reciclar con tanta frecuencia, porque es posible que las ventajas del reciclaje no compensen el costo que representa detener el proceso de trabajo, volver a cargar las páginas y volver a obtener los recursos y datos.

Las aplicaciones web ASP.NET que se ejecutan en Windows Server 2003 e IIS 6.0 no requieren un ajuste del modelo de procesamiento, porque ASP.NET utilizará los valores del modelo de procesamiento de IIS 6.0.
Ajuste el número de subprocesos por proceso de trabajo correctamente para la aplicación La arquitectura de solicitud de ASP.NET intenta lograr un equilibrio entre el número de subprocesos que ejecutan solicitudes y los recursos disponibles. La arquitectura solo permite ejecutar de forma simultánea el número de solicitudes que admite la potencia disponible de la CPU. Esta técnica se conoce como control de subprocesos. No obstante, hay situaciones en las que el algoritmo de control de subprocesos no funciona bien. El control de subprocesos se puede supervisar en el monitor de rendimiento de Windows a través del contador de rendimiento Recuento de instancias de canalización que está asociado al objeto de rendimiento Aplicaciones ASP.NET.

Cuando una página web ASP.NET llama a un recurso externo, como cuando obtiene acceso una base de datos o procesa solicitudes de servicio web ASP.NET, la solicitud de página generalmente se detiene hasta que responde el recurso externo. Esto libera la CPU para que procese otros subprocesos. Si otra solicitud está en espera de ser procesada y se libera un subproceso del grupo de subprocesos, empieza a procesarse la solicitud en espera. El resultado puede ser que se ejecuten concurrentemente muchas solicitudes y queden en espera muchos subprocesos en el proceso de trabajo de ASP.NET o grupo de aplicaciones. Esto puede dificultar el rendimiento del servidor web y afectar negativamente al rendimiento.

Para reducir este efecto en el rendimiento, puede establecer manualmente el límite del número de subprocesos del proceso. Para ello, cambie los atributos MaxIOThreads y MaxWorkerThreads en la sección processModel del archivo Machine.config.

Nota:

Los subprocesos de trabajo son para procesar solicitudes ASP.NET. Los subprocesos de E/S se utilizan para procesar datos de archivos, bases de datos o servicios web ASP.NET.

Los valores que asigne a los atributos del modelo de proceso representan el número máximo de cada tipo de subproceso por CPU del proceso. En un equipo con dos procesadores, el número máximo es dos veces el valor predeterminado. Para los equipos que tengan cuatro procesadores, el número máximo es 4 veces el valor establecido. La configuración predeterminada es adecuada para equipos con uno y dos procesadores. Sin embargo, si existen 100 o 200 subprocesos en el proceso, se puede reducir el rendimiento de los equipos que tienen más de dos procesadores. Si hay demasiados subprocesos en un proceso, éste puede ralentizarse. El servidor debe realizar cambios de contexto adicionales, lo que provoca que el sistema operativo gaste ciclos de CPU para mantener los subprocesos en lugar de procesar las solicitudes. Puede determinar cuál es el número adecuado de subprocesos realizando pruebas de rendimiento en la aplicación.
Para las aplicaciones que se basan en gran medida en recursos externos, habilite una matriz de procesos web en los equipos multiprocesador El modelo de proceso de ASP.NET ayuda a habilitar la escalabilidad en los equipos con varios procesadores distribuyendo el trabajo entre varios procesos, uno por CPU, cada uno con una afinidad del procesador establecida en una CPU. Esta técnica está a veces se denomina hospedaje multiproceso en una única máquina. Las aplicaciones web pueden beneficiar de la matriz de procesos web si utilizan exhaustivamente recursos externos. Por ejemplo, las aplicaciones podrían beneficiarse si utilizan un servidor de bases de datos o si llaman a objetos COM que tienen dependencias externas. Sin embargo, pruebe el rendimiento de una aplicación web en una matriz de procesos web antes de habilitar esta función para un sitio web de producción.

Nota:
Los subprocesos de trabajo son para procesar solicitudes ASP.NET. Los subprocesos de E/S se utilizan para procesar datos de archivos, bases de datos o servicios web ASP.NET.

Prácticas de codificación

En las instrucciones siguientes se ofrecen sugerencias para escribir código eficaz.

No utilice excepciones en el código Las excepciones pueden hacer que el rendimiento disminuya significativamente. Por consiguiente, evite utilizarlas para controlar el flujo normal del programa. Si es posible, incluya lógica en el código para detectar y controlar las condiciones que podrían provocar una excepción. Algunos escenarios comunes que se pueden detectar en el código son comprobar si un valor es null, analizar cadenas como valores numéricos y comprobar valores específicos antes de aplicar operaciones matemáticas. Los ejemplos siguientes muestran código que puede causar una excepción y código alternativo que comprueba una condición. Ambos ejemplos producen el mismo resultado.
```
// This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

// This is preferred.
if (num != 0)
   result = 100 / num;
else
  result = 0;
```
```
' This is not recommended.
Try
   result = 100 / num
Catch (e As Exception)
  result = 0
End Try

' This is preferred.
If Not (num = 0)
   result = 100 / num
Else
  result = 0
End If
```