2010-08-14 9 views

Respuesta

8

No se puede adivinar que ThrowException() es un método que siempre arroja excepciones. Para eso, necesitarías un análisis de código estático.

El análisis del código estático está disponible en VS 2010, pero solo para las versiones más caras de VS, creo.

+5

Absolutamente correcto. Pero para aclarar el punto OP, si cambia el método ThrowException() para devolver una excepción y cambie el código a: throw ThrowException(), se comportaría como el OP deseado. –

+1

Bueno, VS 2008 tiene análisis de código estático, de lo contrario no generaría este error. – Chris

+0

@Kirk: No entiendo por qué. Ni siquiera me da el punto de tener un método que siempre arroje una excepción. Aunque creo que esto es más una cuestión teórica. –

1

La rama else no tiene una declaración return. Eso significa que Foo no devuelve un valor al ingresar a la rama else.

¿Por qué no hacer:

public int Foo(bool flag) 
{ 
    if (!flag) { 
     ThrowException(); 
    } 

    return 1; 
} 

Por cierto que siempre sienten que la validación se debe hacer primero.

+0

Gracias - es una buena idea – Chris

+0

Sí, también creo que este código es mucho más comprensible. Además tiene menos sangría. –

0

El mensaje de error lo dice todo: no todas las rutas de códigos devuelven un valor. Creo que el propósito de ThrowException() es lanzar una excepción. Si lo hace, puedo ver cómo el mensaje de error parece extraño. Sin embargo, considere la consecuencia de aceptar esto como un código válido. Si la implementación de ThrowException() se modificó en un momento posterior para dejar de emitir una excepción, el código anterior fallará de repente, y eso probablemente sea una gran sorpresa. El compilador está escogiendo el camino seguro aquí.

Cuestiones relacionadas