I just want to know is it safe/ good approach to call return inside a using block.
For ex.
using(var scope = new TransactionScope())
{
// my core logic
return true; // if condition met else
return false;
scope.Complete();
}
We know the at the last most curly brace dispose() will get called off. But what will be in the above case, since return jumps the control out of the given scope (AFAIK)...
Is my scope.Complete() get called? And so for the scope's dispose() method.
using{} scope is over, the relevant objects get disposed, return will "break" the scope - so the objects will get disposed as expected
scope.Complete() call will never be hit with the sample you provided, so you're transaction will always rollback.
using's dispose() is called, when the you return, the function containing this using block will have returned and everything belonging to it will be orphaned. So even if scope had not been disposed "by the using" (it will be, as others explained) it will be disposed anyway because the function ended. If C# had goto statement -are you done laughing yet? good- then instead of return you could goto to after the closing brace, without returning. Logically, scope would still be disposed, but you've just put goto in C# so who cares about logic at that stage.
It's perfectly safe to call return inside your using block, since a using block is just a try/finally block.
In your example above after return true, the scope will get disposed and the value returned. return false, and scope.Complete() will not get called. Dispose however will be called regardless since it reside inside the finally block.
Your code is essentially the same as this (if that makes it easier to understand):
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();
}
Please be aware that your transaction will never commit as there's no way to get to scope.Complete() to commit the transaction.
That's fine - finally clauses (which is what the closing curly brace of the using clause does under the hood) always get executed when the scope is left, no matter how.
However, this is only true for statements that are in the finally block (which cannot be explicitly set when using using). Therefore, in your example, scope.Complete() would never get called (I expect the compiler to warn you about unreachable code though).
In general, it is a good approach. But in your case, if you return before calling the scope.Complete(), it will just trash the TransactionScope. Depends to your design.
So, in this sample, Complete() is not called, and scope is disposed, assuming it is inheriting IDisposable interface.
scope.Complete should definitely be called before return. Compiler will display a warning and this code will never be called.
Regarding return itself - yes, it is safe to call it inside using statement. Using is translated to try-finally block behind the scene and finally block is to be certainly executed.
In the example you have provided, there is a problem; scope.Complete() is never called. Secondly, it is not a good practice to use return statement inside using statements. Refer to the following:
using(var scope = new TransactionScope())
{
//have some logic here
return scope;
}
In this simple example, the point is that; the value of scope will be null when using statement is finished.
So it is better not to return inside using statements.
scope will not be null - the only thing that will have happened is that Dispose() will have been invoked on that instance, and therefore the instance should not be used anymore (but it isn't null and there's nothing preventing you to try and use the disposed object, even though this indeed is an inappropriate use of a disposable object).
return scope returns a reference to that object. This way, if you assign that reference on return you prevent the GC from cleaning up the disposed object.
In this example, scope.Complete() will never execute. However, the return command will cleanup everything that is assigned on the stack. The GC will take care of everything that is unreferenced. So, unless there is an object that can not be picked up by the GC, there is no problem.
Follow WeChat
Success story sharing
Want to stay one step ahead of the latest teleworks?
Subscribe Now相似问题
- Should 'using' directives be inside or outside the namespace?
- Can't operator == be applied to generic types in C#?
- Concat all strings inside a List<string> using LINQ
- Are there any side effects of returning from inside a using() statement?
- Why Response.Redirect causes System.Threading.ThreadAbortException?
- In Python, if I return inside a "with" block, will the file still close?
Disposewill get called. If the OP doesn’t know what happens inusing, chances are he doesn’t know what happens withfinally.using, e.g.using (var callersVar = MyFunc(..)) .., instead of having the using inside "MyFunc" - I mean the caller is given the stream and is responsible for closing it viausingor explicitly, or (b) have MyFunc extract whatever info is needed into other objects, that can be safely passed back - then the underlying data objects or stream can be disposed by yourusing. You should not have to write leaky code.