2010-06-21 8 views
6

En .NET, al detectar excepciones, ¿siempre debería atrapar las excepciones derivadas (por lo tanto, no ArgumentException sino los tipos derivados)?¿Capturas la mayoría de las excepciones derivadas?

también:

Si se me pide que utilizar los códigos de error, esto sería en el constructor como tal ?:

tiro nueva excepción ("4000", ex);

¿O un tipo de excepción personalizada con una propiedad de código de error? (Esto puede ser confuso con tipos de excepciones como SqlException que tienen correlaciones de códigos de error con errores de SQL Server).

Gracias

+0

¿De dónde vienen los códigos de error? ¿Son esos códigos de error códigos de error Win32 nativos? –

Respuesta

6
  1. Captura la excepción más amplia que usted sabe cómo manejar.

    En general, esto significa que atrapará una excepción bastante específica. Y algunas excepciones, como ArgumentException s, no se deben capturar en absoluto b/c indican un error de lógica en lugar de un error de tiempo de ejecución. Un lugar donde he encontrado que atrapa una excepción más amplia útil es en el caso de File I/O. Un IOException puede ser una práctica excepción de nivel superior para atrapar.

  2. Si se le pide que use códigos de error, puede salirse con la suya usando la propiedad del mensaje de una excepción para envolverlo, pero nunca lo usaría como una razón para evitar arrojar una excepción apropiadamente tipada. Esto se debe a que hay dos preocupaciones separadas aquí:

    a. El código de error está allí para proporcionar una información específica que se puede buscar en el caso de una falla en el campo. Nunca se debe usar para discriminar entre tipos de excepciones mediante programación b/c el idioma tiene una función específica diseñada para eso: tipos de excepción.

    b. La excepción apropiadamente tipada está allí para proporcionar una forma programática de distinguir entre excepciones. El lenguaje está diseñado para eso, úselo. No siempre arroje un simple Exception.

    Probablemente arrojaré un código de error en el Exception.Data collection. Esto evita sobrescribir mensajes en Exception.Message que de otra manera serían muy útiles para fines de diagnóstico.

+0

No estoy seguro de que haya mucha base en general para considerar ArgumentException más o menos "severa" que muchos otros tipos. Lo que uno realmente necesita saber cuando atrapa una excepción es el estado del sistema (y si la rutina que arrojó la excepción lo ha afectado).Si intenta, por ejemplo, analizar un archivo, no estoy seguro de que valga mucho la validación de todos los campos antes de llamar a rutinas que lanzarían ArgumentException si sus argumentos no son válidos, a menos que mi propio código pueda hacer algo más útil que lanzar una excepción dada la entrada no válida. Así que apenas veo que implica "error de lógica". – supercat

2

Esto depende de si desea capturar una excepción exacta o un grupo de diferentes tipos de excepciones.

A veces se desea agregar el manejo solo para 1 excepción exacta. Otras veces, el manejo de su excepción será el mismo para cualquier tipo de excepción, por lo que puede simplemente ponerle un límite o simplemente tomar Exception para ver cuál es la excepción.

Por ejemplo, es posible que desee capturar solo 1 excepción exacta y ningún otro manejo de excepciones. Podrías hacer eso cuando conozcas más arriba en la pila de llamadas que estás captando el resto de las excepciones, pero quieres ignorar exactamente la que estás capturando exactamente.

Cuestiones relacionadas