CLR Inside Out
Control dañado estado de excepciones
Andrew Pardoe
Esta columna se basa en una versión preliminar de 2010 de Visual Studio. Toda la información está sujeta a cambios.
Contenido
¿Qué son exactamente excepciones?
Excepciones de SEH de Win32 y System.Exception
SEH y código administrado
Excepciones de estado dañado
Es todavía erróneo utilizar catch (e excepción)
Código razonablemente
¿Tiene alguna vez escrito el código que no es muy correcto pero esté suficientemente cerca? ¿Ha tenido que escribir código que funciona bien cuando todo va bien, pero no está muy seguro de qué ocurrirá cuando algo va mal? Hay una instrucción simple y incorrecta que probablemente se sentado en algún código que se ha escrito o han tenido que mantener: detectar (excepción e). Parece inocente tenga y sencillo, pero esta instrucción poco puede provocar una gran cantidad de problemas cuando no puede hacer que se espera.
Si ya ha visto alguna vez código que utiliza las excepciones no de la forma en el siguiente código, entonces se necesita leer esta columna:
public void FileSave(String name)
{
try
{
FileStream fs = new FileStream(name, FileMode.Create);
}
catch (Exception)
{
throw new System.IO.IOException("File Open Error!");
}
}
El error en este código es común: es más sencillo escribir código para detectar todas las excepciones que consiste en detectar exactamente las excepciones que se podría provoca mediante la ejecución de código en el bloque try. Pero por intercepción de la base de la jerarquía de excepción, se finalizar swallowing una excepción de cualquier tipo y lo convierte en un IOException.
Control de excepciones es una de esas áreas sobre qué la mayoría de los usuarios tengan un conocimiento práctico en lugar de un conocimiento profundo. Empezará con un poco de información general explica el control desde el punto de vista CLR para aquellos que esté más familiarizado con el control de programación nativa o un libro de texto universitario antiguo de excepciones de excepciones. Si eres un pro antiguo en control de excepciones administradas, dude en vaya por adelantado a la sección de distintos tipos de excepciones o el código administrado y estructurado de control de excepciones (SEH) en. Asegúrese de que lea las secciones de algunas últimos, aunque.
¿Qué son exactamente excepciones?
Una excepción es la señal que provoca cuando se detecta una condición de que no se esperaba en la ejecución normal de un subproceso de programa. Varios agentes pueden detectar condiciones incorrectas y provocar excepciones. Código de programa (o el código de biblioteca que utiliza) puede producir tipos derivados de System.Exception, el motor de ejecución de CLR puede provocar excepciones y código no administrado puede provocar excepciones así. Las excepciones provocadas en un subproceso de ejecución siguen el subproceso a través de código nativo y administrado, a través de dominios de aplicación y, si no controla el programa, se tratan como excepciones no controladas por el sistema operativo.
Una excepción indica que algo erróneo ha ocurrido. Aunque todas las excepciones administradas tiene un tipo (como System.ArgumentException o excepción System.ArithmeticException), el tipo sólo es significativo en el contexto en el que se produce la excepción. Un programa puede controlar una excepción si entiende las condiciones que produjeron la excepción que se produzca. Pero si el programa no controla la excepción, podría indicar cualquier número de cosas incorrectas. Y una vez que la excepción dejó el programa, sólo tiene un significado muy general: incorrecta algo ha ocurrido.
Cuando Windows detecta que un programa no controla una excepción, intenta proteger el programa de datos persistentes (archivos en disco, configuración del registro y así sucesivamente) al terminar el proceso. Incluso si la excepción originalmente indicado algún estado programa benignos, inesperado (como si no se extrae de una pila vacía) parece un problema grave cuando Windows detecta, porque el sistema operativo no tiene el contexto para interpretar correctamente la excepción. Un único subproceso en un AppDomain puede reducir una instancia completa de CLR por no controla una excepción (consulte la figura 1 ).
Figura 1 uno subprocesos Unhandled produce excepciones terminar el proceso completo
Si las excepciones son tan peligrosas, ¿por qué son tan popular? Al igual que motorcycles y ve de cadena, la capacidad sin procesar de excepciones hace muy útil. Flujo normal de datos en un subproceso del programa va de función en función de a través de llamadas y devuelve. Cada llamada a una función, crea un marco de ejecución en la pila; cada devolución destruye dicho marco. Aparte de alterar el estado global, el único flujo de datos en un programa se consigue al pasar datos entre marcos contiguos como parámetros de función o los valores devueltos. En ausencia del control de excepciones, cada llamador necesita comprobar el éxito de la función que llame éste (o sólo supone que todo lo que siempre es ACEPTAR).
La mayoría de las API Win32 devolver un valor distinto de cero para indicar un error porque Windows no usa el control de excepciones. El programador tiene que cada llamada de función con el código que comprueba el valor devuelto por la función denominada de ajuste. Por ejemplo, este código de la documentación de MSDN acerca de cómo en archivos de lista en un directorio explícitamente comprueba cada llamada para el éxito. La llamada a FindNextFile(...) se ajusta en una comprobación para ver si la devolución es distinto de cero. Si la llamada no es correcta, a continuación, un independiente funcionar llamada: () GetLastError, proporciona detalles de la condición excepcional. Tenga en cuenta que cada llamada debe se revise el éxito en el siguiente marco como valores devueltos son necesariamente limitados al ámbito local de la función:
// FindNextFile requires checking for success of each call
while (FindNextFile(hFind, &ffd) != 0);
dwError = GetLastError();
if (dwError != ERROR_NO_MORE_FILES)
{
ErrorHandler(TEXT("FindFirstFile"));
}
FindClose(hFind);
return dwError;
Sólo puede pasar una condición de error de la función que contiene la condición inesperada al llamador de esa función. Las excepciones tienen la capacidad de para pasar los resultados de ejecución una función fuera del ámbito de la función actual a cada marco arriba de la pila hasta que alcance el marco que sabe cómo tratar la condición inesperada. Sistema de excepción del CLR (llamado un sistema de excepción de dos pasos) proporciona la excepción para cada predecesora en la pila de llamadas del subproceso, a partir del llamador y continuar hasta que alguna función indica que va a controlar la excepción (esto se conoce como el primer paso).
El sistema de excepción, a continuación, desenredo el estado de cada marco en la pila de llamadas entre donde se produce la excepción y el lugar donde estará controlada (conocida como el segundo paso). Cuando lee la pila, el CLR ejecutará, por último, las cláusulas y cláusulas de errores en cada marco para como unwound. A continuación, se ejecuta la cláusula catch en el marco de control.
Porque el CLR comprueba cada predecesora en la pila de llamadas no hay ninguna necesidad de tener un bloque catch al llamador, la excepción puede detectarse en cualquier lugar por la pila. En lugar de tener código para comprobar inmediatamente el resultado de cada llamada de función, un programador puede controlar errores en un lugar muy lejos de donde se ha producido la excepción. El uso de los códigos de error, requiere al programador inspeccionar y pasar de un código de error en cada marco de pila hasta que alcance el lugar donde se puede controlar la condición errónea. Control de excepciones libera el programador de inspección de la excepción en cada marco de la pila.
Para obtener más en producir tipos de excepción personalizada, consulte" Control de errores: generar tipos de excepción personalizado desde una aplicación de servidor COM + administrado".
Excepciones de SEH de Win32 y System.Exception
Hay un efecto secundario interesante que provienen de la capacidad de detectar excepciones muy lejos de donde se ha producido la excepción. Un subproceso de sistema puede recibir las excepciones de programa de cualquier marco activo de la pila de llamadas sin saber dónde se ha producido la excepción. Pero las excepciones siempre no representan una condición de error que el programa detecta: un subproceso de programa también puede producirse una excepción fuera del programa.
Si de ejecución un subproceso hace un procesador a errores, control se transfiere al kernel del sistema operativo, que presenta el error en el subproceso como una excepción de SEH. Al igual que los catch bloque no sabe donde de pila del subproceso que se ha producido una excepción no necesita saber exactamente en qué momento el núcleo del sistema OPERATIVO provocó la excepción de SEH.
Windows notifica a subprocesos de programa sobre las excepciones del sistema OPERATIVO mediante SEH. Los programadores de código administrado rara vez comprobarán estos ya que el CLR normalmente impide que los tipos de errores indicados por las excepciones de SEH. Pero si Windows provoca una excepción de SEH, CLR proporcionará para el código administrado. Aunque las excepciones de SEH en código administrado son infrecuentes, código administrado no seguro puede generar un STATUS_ACCESS_VIOLATION que indica que el programa ha intentado tener acceso a memoria no es válido.
Para obtener más información de SEH, consulte el artículo de Matt Pietrek" Un curso de bloqueos en las profundidades de Win32 control estructurado de excepciones"en el enero de 1997 emitir de Microsoft Systems Journal .
Las excepciones de SEH son una clase diferente de esas las excepciones provocadas por el programa. Un programa podría provocar una excepción porque intentó mostrar un elemento de una pila vacía o intentó abrir un archivo que no existe. Todas estas excepciones sentido en el contexto de ejecución de su programa. Excepciones de SEH, consulte un contexto de fuera de su programa. Una infracción de acceso (AV), por ejemplo, indica que una escritura ha intentado en la memoria no es válido. A diferencia de los errores de programa, una excepción de SEH indica que la integridad de proceso del motor en tiempo de ejecución puede ha sido comprometida. Pero aunque las excepciones de SEH son diferentes de las excepciones que derivan de System.Exception, cuando el CLR ofrece la excepción de SEH a un subproceso administrado pueden detectarse con una instrucción catch (e excepción).
Algunos sistemas intentan separar estos dos tipos de excepciones. El compilador de Microsoft Visual C++ distingue entre las excepciones provocadas por una instrucción throw de C++ y las excepciones de SEH Win32 si compila el programa con el modificador /eh. Esta separación es útil porque un programa normal no sabe cómo controlar los errores que no provocan. Si un programa de C++ intenta agregar un elemento a un std::vector, debe esperar que la operación puede fallará debido a la falta de memoria, pero un programa correcto mediante las bibliotecas bien escritas no se espera que tratar con una infracción de acceso.
Esta separación es útil para los programadores. Una AV es un problema grave: una escritura inesperada en la memoria críticos del sistema puede afectar a provocar efectos impredecibles a cualquier parte del proceso. Aunque algunos errores SEH, tales como un error de división por cero de resultantes de entrada de usuario incorrecta y unchecked, son menos graves. Aunque un programa con una división por cero es incorrecto, es probable que esto afectará a cualquier otra parte del sistema. De hecho, es probable que un programa de C++ podría controlar un error de división por cero sin destabilizing el resto del sistema. Por lo que aunque esta separación es útil, no bastante expresa la necesidad de los programadores de semántica administrado.
SEH y código administrado
El CLR siempre entregado las excepciones de SEH a código administrado con los mismos mecanismos como las excepciones provocadas por el propio programa. Esto no es un problema siempre que no intente controlar condiciones excepcionales que no se pueden tratar razonablemente código. La mayoría de los programas de forma segura no pueden continuar la ejecución después de una infracción de acceso. Por desgracia, control modelo de excepciones del CLR siempre recomienda a los usuarios detectar estos errores graves al permitir que programas para detectar cualquier excepción en la parte superior de la jerarquía de System.Exception. Pero esto rara vez es lo correcto para realizar.
Escribir catch (excepción e) es un error de programación común porque las excepciones no controladas tener consecuencias graves. Pero podría argumentar que si no sabe qué errores se generará una función, debe proteger contra todos los posibles errores cuando el programa llama a esa función. Esto parece un curso razonable de acción hasta que piensas acerca de lo que implica a continuar la ejecución cuando el proceso, posiblemente, en un estado dañado. A veces, anulando e intente volver a es la opción mejor: nadie le gusta ver un cuadro de diálogo de Watson, pero es mejor reiniciar el programa que para tener los datos dañados.
Programas de intercepción de excepciones que surgen de contextos no comprende es un problema grave. Pero no puede resolver el problema mediante las especificaciones de excepciones o algún otro mecanismo de contrato. Y es importante que programas administrados puedan recibir una notificación de excepciones de SEH porque el CLR es una plataforma para muchos tipos de aplicaciones y los hosts. Algunos hosts, como SQL Server, necesitan tener control total del proceso de su aplicación. Código administrado que interopera con código nativo a veces, debe tratar las excepciones de C++ nativas o excepciones de SEH.
Pero la mayoría de los programadores que escriben catch (excepción e) no realmente desea detectar las infracciones de acceso. .. .Te prefieren que ejecución de su programa se detiene cuando se produce un error muy grave en lugar de permitir que el programa limp junto en un estado desconocido. Esto es especialmente cierto para programas que host administra complementos, como Visual Studio o Microsoft Office. Si un complemento hace que una infracción de acceso y, a continuación, swallows la excepción, el host podría hacer daños en su propio estado o los archivos de usuario sin nunca darse cuenta que algo fue mal.
En la versión 4 de CLR, el equipo de producto está realizando las excepciones que indicar un estado dañado proceso diferente de todas las excepciones. Se designa sobre las excepciones de SEH una docena para indicar el estado dañado el proceso. La designación está relacionado con el contexto en que se provoca la excepción contraposición con el propio tipo de excepción. Esto significa que una infracción de acceso recibida de Windows se marcarán como una excepción de estado dañado (CSE), pero una generados en el código de usuario por throw escribir que System.AccessViolationException nuevo no se marcarán como un CSE. Si haber asistido a PDC 2008, recibe una comunidad de tecnología de vista previa de Visual Studio 2010 que incluye estos cambios.
Es importante tener en cuenta que la excepción no dañará el proceso: la excepción se produce después de que se detecta una corrupción en el estado del proceso. Por ejemplo, cuando una operación de escritura a través de un puntero en código no seguro hace referencia a memoria que no pertenece al programa, se provoca un error de infracción de acceso. La escritura ilegal realmente no se produce, el sistema operativo comprueba la propiedad de la memoria y se impide la acción de lugar de tomar. La infracción de acceso indica que el puntero propio estaba dañado en un momento anterior en la ejecución del subproceso.
Excepciones de estado dañado
En la versión 4 y posteriores, el sistema de excepciones de CLR no entregará CSEs a código administrado a menos que el código expresamente haya indicado que puede controlar las excepciones de estado del proceso dañado. Esto significa que una instancia de catch (excepción e) en el código administrado no tiene la CSE presentan a él. Al realizar el cambio dentro del sistema de excepciones CLR no tendrá que cambiar la jerarquía de excepción ni alterar la semántica del control de excepciones cualquier lenguaje administrado.
Por motivos de compatibilidad, el equipo de CLR proporciona algunas formas de permitirle ejecutar el código anterior en el comportamiento antiguo:
- Si desea volver a compilar el código creado en Microsoft .NET Framework 3.5 y ejecutarla en la 4.0 de .NET Framework sin tener que actualizar el origen, puede agregar una entrada en el archivo de configuración de aplicación: legacyCorruptedStateExceptionsPolicy = true.
- Ensamblados compilados con .NET Framework 3.5 o una versión anterior del motor en tiempo de ejecución será capaz de procesar las excepciones de estado dañado (en otras palabras, mantener el comportamiento antiguo) cuando se ejecuta en el 4.0 de .NET Framework.
Si desea que el código para controlar CSEs, deberá indicar su intención, marcando la función que contiene la cláusula de excepciones (catch, finally, o fault) con un nuevo atributo: System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions. Si se produce un CSE, el CLR llevará a cabo su búsqueda de una cláusula catch coincidente pero sólo se busca en las funciones marcadas con el atributo HandleProcessCorruptedStateExceptions (consulte la figura 2 ).
La Figura 2 con HandleProcessCorruptedStateExceptions
// This program runs as part of an automated test system so you need
// to prevent the normal Unhandled Exception behavior (Watson dialog).
// Instead, print out any exceptions and exit with an error code.
[HandledProcessCorruptedStateExceptions]
public static int Main()
{
try
{
// Catch any exceptions leaking out of the program
CallMainProgramLoop();
}
catch (Exception e) // We could be catching anything here
{
// The exception we caught could have been a program error
// or something much more serious. Regardless, we know that
// something is not right. We'll just output the exception
// and exit with an error. We won't try to do any work when
// the program or process is in an unknown state!
System.Console.WriteLine(e.Message);
return 1;
}
return 0;
}
Si se encuentra una cláusula catch adecuado, el CLR desenredo la pila como normal, pero sólo ejecute, por último y errores bloques (y en C#, la implícita, por último, bloquear de utilizar una instrucción) en las funciones marcadas con el atributo. Se omite el atributo HandleProcessCorruptedStateExceptions cuando se encuentra en el código de confianza parcial o transparente porque un host de confianza no desea un que no son de confianza complemento para capturar y omitir estas excepciones graves.
Es todavía erróneo utilizar catch (e excepción)
Aunque el sistema de excepciones CLR marca las excepciones peores como CSE, es aún no una buena idea escribir catch (excepción e) en el código. Las excepciones representan un espectro completo de situaciones inesperados. El CLR puede detectar las excepciones peores, las excepciones de SEH que indicar un estado de proceso posiblemente dañado. Pero otras condiciones inesperados aún pueden ser perjudiciales si se omite o tratan con genérica.
En ausencia de daños en proceso, el CLR ofrece algunos bastante seguras garantías sobre seguridad de la corrección y la memoria del programa. Al ejecutar un programa escrito en código de lenguaje intermedio de Microsoft (MSIL) seguro que puede estar seguro de que todas las instrucciones en el programa se ejecutará correctamente. Pero hacer lo que las instrucciones de programa decir que a menudo es diferente de hacer lo que desea que el programador. Un programa que sea totalmente correcto según el CLR puede dañar el estado de persistente, como los archivos de programa escritos en un disco.
Tomemos como un ejemplo sencillo de un programa que administra una base de datos de exámenes de un Instituto. El programa utiliza principios de diseño orientado a objetos para encapsular los datos y provoca excepciones administradas para indicar eventos inesperados. Un día la secretary escuela aciertos de la tecla ENTRAR una demasiado muchas veces al generar un archivo de puntuación. El programa intenta extrae un valor de una cola vacío y provoca una QueueEmptyException que va no controlada por los marcos en la pila de llamadas.
En algún lugar cerca de la parte superior de la pila es una función, GenerateGrades(), con una cláusula de try/catch que detecta la excepción. Desgraciadamente, GenerateGrades() no tiene idea que los alumnos se almacenan en una cola y no tiene ninguna idea de qué hacer con un QueueEmptyException. Pero el programador que escribió GenerateGrades() no desea que el programa de bloqueo sin guardar los datos que se ha calculado hasta. Todo lo que se escribe de forma segura en el disco y sale del programa.
El problema con este programa es el que realiza una serie de hipótesis que puede ser incorrecta. ¿Cuál es decir que la entrada que falta en la cola de los alumnos es el final? Quizás el primer alumno grabar got omitir, o la décima parte. La excepción indica sólo el programador que el programa es incorrecto. Realizar cualquier acción: Guardar datos en disco o "recuperación" y continuar con la ejecución, es simplemente error. Ninguna acción correcta es posible sin conocimiento del contexto en el que se ha producido la excepción.
Si el programa tenía detecta una excepción específica cercanos al que se ha producido la excepción, es posible que ha sido capaz de realizar la acción adecuada. El programa sabe lo que significa un QueueEmptyException en la función que intenta dequeue a los alumnos. Si la función detecta esa excepción por tipo, en vez de detectar una clase completa de tipos de excepción, que sería en una posición mucho mejor para intentar realizar el estado del programa correctas.
En general, detectar una excepción específica es la lo correcto ya que proporciona el contexto de la mayoría de los que el controlador de excepciones. Si el código potencialmente puede detectar excepciones dos, a continuación, debe estar capaz de tratar con ambos. Escribir código que dice catch (excepción e) tiene que ser capaz de tratar, literalmente, cualquier situación excepcional. Eso es una promesa que es muy difícil de mantener.
Algunos idiomas intentan evitar que los programadores detectar una clase amplia de excepciones. Por ejemplo, C++ tiene las especificaciones de excepción, un mecanismo que permite que un programador especificar qué excepciones pueden se provoca en esa función. Java esto tiene un paso más allá con excepciones activados, un requisito de compilador exige que se especifique una determinada clase de excepciones. En ambos idiomas, se enumeran las excepciones que pueden extenderse fuera de esta función de la declaración de función y los llamadores tienen que controlar dichas excepciones. Las especificaciones de excepción son una buena idea, pero hayan mixto resultados en la práctica.
Hay debate exhaustiva como para si cualquier código administrado debe poder controlar CSEs. Normalmente estas excepciones indican un error de nivel de sistemas y sólo deben controlarse mediante código que entienda el contexto de nivel de sistemas. Aunque la mayoría de las personas no necesita la capacidad de controlar CSEs, hay un par de situaciones donde es necesario.
Un escenario es cuando está muy cerca a donde ha ocurrido con la excepción. Por ejemplo, considere un programa que llama a código nativo que se sabe que se buggy. Depuración en el código que ha aprendido que ceros en ocasiones, un puntero antes de tener acceso a ella, que produce una infracción de acceso. Quizás desee utilizar el atributo HandleProcessCorruptedStateExceptions en la función que llama a código nativo mediante P/Invoke ya que se conoce la causa de los daños de puntero y se sienten cómodos que se mantiene la integridad del proceso.
El otro escenario que puede llamar para el uso de este atributo es cuando se encuentre lo que puede del error. De hecho, está casi listo para salir de su proceso. Supongamos que ha escrito un host o un marco que desea realizar algún registro personalizado en caso de un error. Puede ajustar la función principal con un bloque try/catch/finally y marcarlo con HandleProcessCorruptedStateExceptions. Si un error inesperadamente hace todo copia función principal del programa de la, es escribir algunos datos en el registro, realizando trabajo poco tal como se ha a y salir del proceso. Cuando la integridad del proceso de es en cuestión cualquier trabajo que realiza podría ser peligroso, pero si el registro personalizado falla en ocasiones es aceptable.
Eche un vistazo al diagrama que se muestra en la figura 3 . Función aquí 1 (fn1()) se atribuye con [HandleProcessCorruptedStateExceptions] por lo que la cláusula catch detecta la infracción de acceso. El, por último, bloque en función de 3 no se ejecuta, aunque se se detecta la excepción en función de 1. Función 4 en la parte inferior de la pila provoca un error de infracción de acceso.
La figura 3 excepciones y infracción de acceso
No hay ninguna garantía de en cualquiera de estos escenarios que lo que está haciendo es completamente seguro, pero existen escenarios donde sólo terminar el proceso es inaceptable. Sin embargo, si decide controlar un CSE hay una gran carga en el como el programador para hacerlo correctamente. Recuerde que el sistema de excepciones CLR incluso no entregar un CSE a cualquier función que no está marcado con el nuevo atributo bien durante el primer paso (cuando busca una cláusula catch coincidente) o la segunda fase (cuando lee el estado de cada marco y se ejecuta, por último y bloques de errores).
El, por último, bloque existe en orden para garantizar que el código siempre se ejecuta, si se hay una excepción o no. (Bloques fault ejecutar sólo cuando se produce una excepción, pero tienen una garantía similar de siempre que se ejecuta). Estas construcciones se utilizan para limpiar recursos críticos como liberar identificadores de archivo o contextos de suplantación de reversión.
Incluso el código que se escribe en ser confiable a través del uso de limita las regiones (CER, Constrained Execution REGION) no se ejecuta cuando se ha producido un CSE a menos que esté en una función que se ha marcado con el atributo HandleProcessCorruptedStateExceptions de ejecución. Es muy difícil escribir código correcto que controla un CSE y continúa con ejecutar el proceso de forma segura.
Examine estrechamente el código en la figura 4 para ver lo que puede ir mal. Si este código no se encuentra en una función que puede procesar CSEs, a continuación, el, por último, bloque no se ejecutará cuando ocurre una infracción de acceso. Está bien si el proceso termina, se liberará el identificador de archivo abierto. Pero si algún otro código detecta la infracción de acceso y se intenta restaurar estado, debe saber que tiene a cerrar este archivo, así como restaurar cualquier otro estado externo que ha cambiado este programa.
La figura 4 el finally no puede ejecutar bloqueo
void ReadFile(int index)
{
System.IO.StreamReader file =
new System.IO.StreamReader(filepath);
try
{
file.ReadBlock(buffer, index, buffer.Length);
}
catch (System.IO.IOException e)
{
Console.WriteLine("File Read Error!");
}
finally
{
if (file != null)
{
file.Close()
}
}
}
Si decide que se va a controlar un CSE, el código necesita esperar a que hay una gran cantidad de estado crítico que no se ha unwound. Por último y no se han ejecutado bloques de errores. No se han ejecutado las regiones de ejecución limitada. El programa y el proceso, se encuentran en un estado desconocido.
Si conoce que el código haga lo correcto, sabrá qué hacer. Pero si no estás seguro del estado de su programa se ejecuta en, entonces es mejor permitir sólo el proceso de salir. O, si la aplicación está alojada, invocar la directiva de asignación que ha especificado el host. Consulte Alessandro Catorcini y Brian Grunkemeyer Columna de CLR Inside Out de diciembre de 2007 Para obtener más información sobre cómo escribir código confiable y las CER.
Código razonablemente
Aunque el CLR impide naively detectar CSEs, es aún no una buena idea para detectar demasiado amplias clases de excepciones. Pero catch (excepción e) aparece en una gran cantidad de código, y es improbable que esto cambiará. Al no ofrecer las excepciones que representan un estado dañado del proceso al código que naively detecta todas las excepciones, evitar este código que realice un peor situación graves.
La próxima vez que escribe o mantener código que detecta una excepción, piense en lo que significa la excepción. ¿Indica el tipo detectado coincidencia que el programa (y las bibliotecas que se utiliza) se documentan que se va a producir? ¿Sabe cómo controlar la excepción, que el programa pueda correctamente y segura continuar ejecución?
Control de excepciones es una herramienta eficaz que debe utilizarse cuidadosamente y thoughtfully. Si realmente necesita utilizar esta característica, si realmente tiene que tratar las excepciones que puedan indicar un proceso está dañado, el CLR se confía y permitirle hacerlo. Simplemente tenga cuidado y hacerlo correctamente.
Envíe sus preguntas y comentarios a clrinout@Microsoft.com.
Andrew Pardoe es un administrador de programas de CLR de Microsoft. Trabaja en muchos aspectos del motor de ejecución para el escritorio y runtimes Silverlight. Puede ponerse en Andrew.Pardoe@Microsoft.com.