Solo quiero saber si es seguro / buen enfoque llamar returndentro de un usingbloque.
Por ej.
using(var scope = new TransactionScope())
{
// my core logic
return true; // if condition met else
return false;
scope.Complete();
}
Sabemos dispose()que se cancelará la última llave más rizada . Pero lo que será en el caso anterior, ya que returnsalta el control fuera del alcance dado (AFAIK) ...
scope.Complete()llaman?dispose()método del osciloscopio .scope.Complete()llamada nunca se verá afectada con la muestra que proporcionó, por lo que su transacción siempre se revertirá.
using's dispose(), cuando regrese, la función que contiene este usingbloque habrá regresado y todo lo que le pertenezca quedará huérfano. Entonces, incluso si scopeno se hubiera eliminado "por using" (lo será, como otros explicaron), se eliminará de todos modos porque la función terminó. Si C # tuviera una gotodeclaración, ¿ya terminaste de reír? bueno, entonces en lugar de regresar, podría gotohacerlo después de la llave de cierre, sin regresar. Lógicamente, scopetodavía se eliminaría, pero acaba de poner gotoC #, así que a quién le importa la lógica en esa etapa.
Respuestas:
Es perfectamente seguro llamar returndentro de su usingbloque, ya que un bloque de uso es solo un try/finallybloque.
En su ejemplo anterior, después de la devolución true, el alcance se eliminará y se devolverá el valor. return falseY scope.Complete()se no ser llamado. Disposesin embargo, se llamará independientemente, ya que reside dentro del bloque finalmente.
Su código es esencialmente el mismo que este (si eso lo hace más fácil de entender):
var scope = new TransactionScope())
try
{
// my core logic
return true; // if condition met else
return false;
scope.Complete();
}
finally
{
if( scope != null)
((IDisposable)scope).Dispose();
}
Tenga en cuenta que su transacción nunca se confirmará, ya que no hay forma de llegar scope.Complete()a confirmar la transacción.
Dispose se llamará. Si el OP no sabe qué sucede en using, es probable que no sepa qué sucede finally.
using, por ejemplo using (var callersVar = MyFunc(..)) .., en lugar de usar dentro de "MyFunc" - me refiero a que la persona que llama recibe la transmisión y es responsable de cerrarla vía usingo explícitamente, o (b) Haga que MyFunc extraiga toda la información necesaria en otros objetos, que se pueden transferir de forma segura; luego, su using. No debería tener que escribir código con fugas.
Eso está bien: las finallycláusulas (que es lo que hace la llave de cierre de la usingcláusula debajo del capó) siempre se ejecutan cuando se deja el alcance, sin importar cómo.
Sin embargo, esto solo es cierto para las declaraciones que están en el bloque finalmente (que no se puede establecer explícitamente cuando se usa using). Por lo tanto, en su ejemplo, scope.Complete()nunca se llamaría (aunque espero que el compilador le advierta sobre el código inalcanzable).
En general, es un buen enfoque. Pero en su caso, si regresa antes de llamar al scope.Complete(), simplemente eliminará el TransactionScope. Depende de tu diseño.
Entonces, en este ejemplo, no se llama a Complete () y se elimina el alcance, asumiendo que hereda la interfaz IDisposable.
Alcance Definitivamente se debe llamar a Complete antes return. El compilador mostrará una advertencia y este código nunca se llamará.
Con respecto a returnsí mismo, sí, es seguro llamarlo usingdeclaración interna . El uso se traduce en intentar, finalmente bloquear detrás de la escena y finalmente bloquear debe ejecutarse.
En el ejemplo que ha proporcionado, hay un problema; scope.Complete()nunca se llama. En segundo lugar, no es una buena práctica utilizar returndeclaraciones dentro de usingdeclaraciones. Consulte lo siguiente:
using(var scope = new TransactionScope())
{
//have some logic here
return scope;
}
En este simple ejemplo, el punto es que; el valor de scopeserá nulo cuando finalice el uso de la instrucción.
Así que es mejor no volver al interior usando declaraciones.
scopeno será nula - la única cosa que va a haber sucedido es que Dispose()se han invocado en esa instancia, y por lo tanto la instancia debe no utilizar más (pero no es nula y no hay nada que impida que pruebe y el uso el objeto desechado, aunque se trate de un uso inadecuado de un objeto desechable).
return scopedevuelve una referencia a ese objeto. De esta forma, si asigna esa referencia a la devolución, evita que el GC limpie el objeto desechado.
Para asegurarse de que scope.Complete()se llamará, envuélvalo con try/finally. Se disposellama porque lo ha envuelto con el usingque es un try/finallybloque alternativo .
using(var scope = new TransactionScope())
{
try
{
// my core logic
return true; // if condition met else
return false;
}
finally
{
scope.Complete();
}
}
using{}se termina el alcance, los objetos relevantes se eliminan,return"romperán" el alcance, por lo que los objetos se eliminarán como se esperaba