Solución:
Advertencia del compilador (nivel 2) CS0162
Código inaccesible detectado
El compilador detectó código que nunca se ejecutará.
Que es solo decir, el Compilador entiende lo suficiente a través de Análisis estático que no se puede alcanzar y lo omite por completo del IL compilado (de ahí su advertencia).
Nota : Puede probarse este hecho a sí mismo intentando pasar al código inalcanzable con el depurador o utilizando un explorador de IL.
los finally puede ejecutarse en un Excepción, (aunque aparte de eso) no cambia el hecho (en este caso) seguirá siendo un Excepción no detectada. Ergo, el último return nunca será golpeado independientemente.
-
Si desea que el código continúe hasta el último
return, tu única opción es Captura los Excepción; -
Si no lo hace, déjelo como está y quite el
return.
Ejemplo
try
{
command.CommandText = sb.ToString();
returnValue = command.ExecuteNonQuery();
return returnValue == 1;
}
catch(<some exception>)
{
// do something
}
finally
{
command.Dispose();
}
return false;
Cotizar la documentación
probar-finalmente (Referencia de C #)
Al usar un bloque finalmente, puede limpiar cualquier recurso que esté asignado en un bloque try, y puede ejecutar código incluso si ocurre una excepción en el bloque try. Normalmente, las sentencias de un bloque finalmente se ejecutan cuando el control deja una sentencia try. La transferencia de control puede ocurrir como resultado de la ejecución normal, de la ejecución de una instrucción break, continue, goto o return, o de la propagación de una excepción fuera de la instrucción try.
Dentro de una excepción manejada, se garantiza la ejecución del bloque finalmente asociado. Sin embargo, si la excepción no se controla, la ejecución del bloque finalmente depende de cómo se desencadena la operación de desenrollado de la excepción. Eso, a su vez, depende de cómo esté configurada su computadora.
Por lo general, cuando una excepción no controlada finaliza una aplicación, no es importante si el bloque finalmente se ejecuta o no. Sin embargo, si tiene sentencias en un bloque finalmente que deben ejecutarse incluso en esa situación, una solución es agregar un bloque de captura a la sentencia try-finalmente. Alternativamente, puede detectar la excepción que podría lanzarse en el bloque try de una declaración try-finalmente más arriba en la pila de llamadas. Es decir, puede detectar la excepción en el método que llama al método que contiene la instrucción try-finalmente, o en el método que llama a ese método, o en cualquier método de la pila de llamadas. Si no se detecta la excepción, la ejecución del bloque finalmente depende de si el sistema operativo elige desencadenar una operación de desenrollado de excepción.
Finalmente
Cuando utilice cualquier cosa que admita IDisposable interfaz (que está diseñada para liberar recursos no administrados), puede envolverla en una using declaración. El compilador generará un try {} finally {} y llamar internamente Dispose() en el objeto.
el bloque finalmente se ejecutará, luego ejecutará el retorno falso; en el fondo.
Incorrecto. finally no se traga la excepción. Lo respeta y la excepción se lanzará con normalidad. Solo ejecutará el código en el final antes de que finalice el bloque (con o sin excepción).
Si desea que se trague la excepción, debe usar un catch bloque sin throw en eso.
La advertencia es porque no usaste catch y tu método está básicamente escrito así:
bool SomeMethod()
{
return true;
return false; // CS0162 Unreachable code detected
}
Desde que usas finally únicamente para desechar, la solución preferida es utilizar using patrón:
using(var command = new WhateverCommand())
{
...
}
Eso es suficiente, para asegurar lo que Dispose sera llamado. Se garantiza que se llamará después de la ejecución exitosa del bloque de código o después de (antes) algunos catch abajo en la pila de llamadas (las llamadas de los padres están caídas, ¿verdad?).
Si no se tratara de deshacerse, entonces
try { ...; return true; } // only one return
finally { ... }
es suficiente, ya que lo harás Nunca tengo que volver false al final del método (no hay necesidad de esa línea). Su método es devolver el resultado de la ejecución del comando (true o false) o lanzará una excepción de lo contrario.
Considere también lanzar sus propias excepciones envolviendo las excepciones esperadas (consulte el constructor InvalidOperationException):
try { ... }
catch(SomeExpectedException e)
{
throw new SomeBetterExceptionWithExplanaition("...", e);
}
Por lo general, esto se usa para decir algo más significativo (útil) para la persona que llama de lo que diría la excepción de llamada anidada.
La mayoría de las veces, no te preocupas por las excepciones no controladas. A veces necesitas asegurarte de que finally se llama incluso si la excepción no se controla. En este caso, simplemente lo atrapa usted mismo y vuelve a lanzarlo (vea esta respuesta):
try { ... }
catch { ...; throw; } // re-throw
finally { ... }