18 votos

Compilador de C# debe dar aviso, pero no?

Alguien en mi equipo trató de arreglar una 'variable no se usa' advertencia en un vacío de la cláusula catch.

try { ... } catch (Exception ex) { }

-> da una advertencia acerca de la ex no está siendo utilizado. Tan lejos, tan bueno.

La revisión fue algo como esto:

try { ... } catch (Exception ex) { string s = ex.Message; }

Viendo esto, yo pensé: "genial, así que ahora el compilador se quejará s no se utiliza."

Pero no! No hay ninguna advertencia en ese trozo de código y no puedo entender por qué. Alguna idea?

PS. Sé que captura todas las cláusulas que silenciar las excepciones son una mala cosa, pero eso es un tema diferente. También sé que la advertencia inicial se quita mejor por hacer algo como esto, que no es el punto.

try { ... } catch (Exception) { }

o

try { ... } catch { }

25voto

Eric Lippert Puntos 300275

En este caso, el compilador detecta que está escrito pero no leer, y deliberadamente suprime la advertencia.

La razón es debido a que C# es un recolector de basura idioma, lo creas o no.

¿Cómo entender eso?

Así, considere lo siguiente.

Tiene un programa que llama a un método DoIt() que devuelve una cadena. Usted no tiene el código fuente para DoIt(), pero desea examinar en el depurador lo que su valor de retorno es.

Ahora en tu caso en particular que usted está usando DoIt() por sus efectos secundarios, no su valor de retorno. Así que le dices

DoIt(); // discard the return value

Ahora estás depurando tu programa y te va a mirar a la devolución del valor de DoIt() y no lo hay porque en el momento en que el depurador se rompe después de la llamada a DoIt(), el recolector de basura podría ya haber limpiado la parte no utilizada de la cadena.

Y, de hecho, el administrado depurador no tiene facilidad para "mirar la cosa devuelto por el método anterior llamada". El C++ no administrado depurador tiene esa característica, ya que se puede ver en el registro EAX donde la descartados valor de retorno es todavía sentado, pero no hay garantía en código administrado que el valor devuelto aún está vivo si fue descartado.

Ahora, uno podría argumentar que esta es una característica muy útil y que el depurador equipo debe agregar una característica por la cual los valores devueltos se mantiene vivo si hay un depurador de breakpoint inmediatamente después de la ejecución del método. Que sería una buena característica, pero soy la persona equivocada para preguntar por ella, ir a pedir el depurador equipo.

¿Cuál es el pobre C# developer hacer? Hacer que una variable local, almacenar el resultado en la variable local y, a continuación, examinar el local en el depurador. El depurador no asegurarse de que los lugareños no son basura que se recoge de forma agresiva.

Así lo hace y luego el compilador da un aviso de que tienes un local que sólo está escrita y nunca de leer porque la cosa haciendo que la lectura no es parte del programa, es el desarrollador sentado allí viendo el depurador. Que es un muy irritante experiencia de usuario! Por lo tanto, se detecta la situación en la que un no-constante de valor se asigna a una variable local o en el campo , que nunca es leer, y suprimir esa advertencia. Si usted cambiar su código para que en vez dice string s = "hello"; , a continuación, usted comenzará a recibir la advertencia, ya que el compilador razones, bien, esto no puede ser, posiblemente, alguien que trabaja en torno a las limitaciones del depurador, porque el valor es allí donde puede ser leído por el desarrollador ya sin el depurador.

Que explica que uno. Hay muchos otros casos en los que se suprimen las advertencias acerca de las variables que se han leído nunca; una detallada exegisis de todas las compilador de políticas para cuando nos informe de las advertencias y cuando no me llevaría bastante tiempo para escribir, así que creo que voy a dejar.

9voto

Gary.Ray Puntos 4042

La variable s se utiliza... para contener una referencia a ex.Mensaje. Si usted acaba de string s; te sale el aviso.

1voto

Nelson Rothermel Puntos 3538

Creo que la persona que responde a esta tendrá una idea de cómo el compilador de las obras. Sin embargo, algo como FxCop probablemente atrapar a este.

1voto

BFree Puntos 46421

Las propiedades son los métodos, y no hay nada que impida a nadie de poner un poco de código que hace algo en el ex.Mensaje de la propiedad. Por lo tanto, mientras que usted no puede hacer nada con s, llamando ex.Mensaje PODRÍA tener valor....

1voto

Dan Diplo Puntos 16133

No es realmente el trabajo de un compilador para el trabajo de cada instancia y en caso de esquina cuando una variable puede o no puede ser utilizado. Algunos son fáciles de detectar, algunos son más problemáticos. Errar en el lado de la precaución es lo más sensato (especialmente cuando las advertencias se puede configurar para ser tratados como errores - imagino que si el software no compilar sólo porque el compilador pensaba que no estaban utilizando algo que se fueron). Compilador de Microsoft team dice específicamente:

"...nuestra guía para los clientes que son interesado en descubrir sin usar los elementos de su código es el uso de FxCop. Se puede descubrir campos sin utilizar y mucho más interesantes datos acerca de su código."

-Ed Maurer, El Desarrollo De Liderar, Gestionar Compilador De La Plataforma

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X