Consider,
static void Main(string[] args)
{
Console.WriteLine(fun());
}
static int fun()
{
int i = 0;
try
{
i = 1;
return i;
}
catch (Exception ex)
{
i = 2;
return i;
}
finally
{
i = 3;
}
}
The sample code outputs "1". but the value of i is changed to 3 in finally block. Why wasn't the value of 'i' changed to 3?
Thank you,
Consider this code- I think the code explains what you are thinking, and how you can make what you think should happen actually happen:
static void Main(string[] args)
{
int counter = 0;
Console.WriteLine(fun(ref counter)); // Prints 1
Console.WriteLine(counter); // Prints 3
}
static int fun(ref int counter)
{
try
{
counter = 1;
return counter;
}
finally
{
counter = 3;
}
}
With this code you return 1 from the method, but you also set the counter variable to 3, which you can access from outside the method.
You have to remember that finally executes after everything else in the try and catch. Place the return statement after the try/catch/finally statement to have it return 3.
I imagine if you use a reference type instead of a value type you'd get different behavior.
When you said "return i"... C# puts that return value in a temporary holding area (memory) and then runs your 'finally' code... if the finally block was able to modify that value, it would defeat the safety/finalism of the finally block.
It's like a using statement with a return inside... the "Dispose" is still going to happen, AFTER the return (so to speak).
Finally is always executed
Your code always executes finally no matter if an exception was thrown or not. So your code should actually be:
try
{
i = 1;
}
catch
{
i = 2;
}
finally
{
i = 3;
}
return i;
But in this trivial case finally block won't make much sense. Because we will always return 3 no matter what happened before that.
Finally is used to release resources
finally block should normally be used when you have to release some system resources allocated within try block (ie. openning a DB connection an reading data in try block and closing it in finally). So they will always get released no matter if there was an exception or not. In this case it doesn't make much sense to use finally block.
Related
In C#.NET, let's take the following example
[WebMethod]
public int TakeAction()
{
try {
//Call method A
Return 1;
} catch (Exception e) {
//Call method B
Return 0;
} finally {
//Call method C
}
}
Now let's say method C is a long running process.
Does the client who invokes TakeAction get back the return value, before method C is invoked, or after it is invoked / completed?
The return value is evaluated first, then the finally block executes, then control is passed back to the caller (with the return value). This ordering is important if the expression for the return value would be changed by the finally block. For example:
Console.WriteLine(Foo()); // This prints 10
...
static int Foo()
{
int x = 10;
try
{
return x;
}
finally
{
// This executes, but doesn't change the return value
x = 20;
// This executes before 10 is written to the console
// by the caller.
Console.WriteLine("Before Foo returns");
}
}
anything in finally block is executed after leaving try block. In your case it either returns 1 or 0 and then executes method c.
for more info on try-catch-finally you can refer this
I'm just wondering why the compiler gives me this error. The try block will be executed every time the function is called and that means the variable will get assigned. But still it doesn't let me compile.
using System;
namespace Checking
{
class Program
{
static void Main(string[] args)
{
int intNum;
intNum = readValue("Please enter a number: ");
}
static int readValue(string strPrompt)
{
int intRes;
Console.WriteLine(strPrompt);
try
{
intRes = Convert.ToInt32(Console.ReadLine()); // Gets assigned here! But still doesnt allow me to compile!
}
catch (Exception ex)
{
Console.WriteLine("Please enter a numeric value.\n");
readValue(strPrompt);
}
return intRes;
}
}
}
Putting return intRes inside the try block allows me to get rid of that error, but then an error crops up saying not all code paths return a value. I understand the errors, but I still don't understand why it won't allow me to compile, the try block gets executed every time right?
I also know that assigning 0 to intRes will get rid of that error.
Regards,
The compiler is right. The variable is not always assigned.
If the conversion fails, the assignment never happens, and the execution continues inside the catch block, where you call the function again, but you have forgotten to assign the return value of that call to the variable:
catch (Exception ex)
{
Console.WriteLine("Please enter a numeric value.\n");
intRes = readValue(strPrompt);
}
Here's an anternative implementation using a while and TryParse:
static int readValue(string strPrompt) {
int intRes = 0;
bool done = false;
while (!done) {
Console.WriteLine(strPrompt);
if (Int32.TryParse(Console.ReadLine(), out intRes) {
done = true;
} else {
Console.WriteLine("Please enter a numeric value.\n");
}
}
return intRes;
}
If Convert.ToInt32 failes, intRes never gets assigned to.
Either set a default value when creating the variable, or assign to in the catch block.
Because if the try fails, intRes has no value
In your catch use
intRes = readValue(strPrompt);
Initialise it with
int intRes = 0;
instead of
int intRes;
You may also want to look at the int.TryParse syntax
You will get an uninitialized intRes if Console.ReadLine() throws an exception. That is why your compiler is complaining.
The compiler has no way to know if your code inside the try block will throw an exception or not.
So, in case your code throws an exception, then the intRes variable will never be assigned.
Consequently the compiler emits the error message.
Also, as it stands, your code has a problem. You try to recursively call readValue inside the catch block to get a correct value but when your user finally enter a correct value, the main will never receive the value entered because you are using a local variable for the result value.
I'm coding a method where an attempt to upload a document is wrapped within a Try/Catch block.
If the attempt fails, I'm incrementing the Retry counter and recursively calling the same method.
I'm not clear on the execution path in those cases where the 'Catch' block is hit. Initial tests show that the 'return null' statement is executed after that first recursive call executes. Perhaps the 'return null' statement needs to be within the Catch block but outside the retries<3 loop?
public RssUploadDocOutput UploadInvoice(string filename, int retries)
{
var returnsOutput = new RssUploadDocOutput();
GoogleSheetsCommand sscmd = new GoogleSheetsCommand("UploadDocument", ConnSheets);
sscmd.CommandType = System.Data.CommandType.StoredProcedure;
sscmd.Parameters.Add(new GoogleSheetsParameter("LocalFile", filename));
//int retries = 0; removed
try
{
GoogleSheetsDataReader rdr = sscmd.ExecuteReader();
rdr.Read();
returnsOutput.ID = rdr[0].ToString();
[...]
returnsOutput.Weblink = rdr[6].ToString();
return returnsOutput;
}
catch (Exception ex)
{
//retries++;
Logger.Instance.LogException(ex);
if (retries < 3)
{
Thread.Sleep(1000 * retries);
UploadInvoice(filename, retries+1);
}
}
return null;
}
Needs two changes:
Declare the variable retries outside of the function
Return the value returned by the UploadInvoice method (in the catch block)
if (retries < 3)
{
Thread.Sleep(1000 * retries);
return UploadInvoice(filename);
}
You need to keep the variable outside your method. Otherwise everytime, it will reset to 0 and you will end up in never ending.....
int retries = 0;
public RssUploadDocOutput UploadInvoice(string filename)
{
//no need of int retries = 0; inside the method
//do stuff
}
your catch block will return null only if it failed all 3 times.
EDIT : You are SILENTLY KILLING the exception. Are you sure you want to do that ?. You may probably want to Log it or Notify back to the caller.
I have an enumerator written in C#, which looks something like this:
try
{
ReadWriteLock.EnterReadLock();
yield return foo;
yield return bar;
yield return bash;
}
finally
{
if (ReadWriteLock.IsReadLockHeld)
ReadWriteLock.ExitReadLock();
}
I believe this may be a dangerous locking pattern, as the ReadWriteLock will only be released if the enumeration is complete, otherwise the lock is left hanging and is never released, am I correct? If so, what's the best way to combat this?
No, the finally block will always be executed, pretty much unless somebody pulls the plug from the computer (well and a few other exceptions).
public static IEnumerable<int> GetNumbers() {
try
{
Console.WriteLine("Start");
yield return 1;
yield return 2;
yield return 3;
}
finally
{
Console.WriteLine("Finish");
}
}
...
foreach(int i in GetNumbers()) {
Console.WriteLine(i);
if(i == 2) break;
}
The output of the above will be
Start12Finish
Note that in C# you write yield return, not just yield. But I guess that was just a typo.
I think David's answered the question you intended to ask (about the enumeration aspect), but two additional points to consider:
What would happen if ReadWriteLock.EnterReadLock threw an exception?
What would happen if ReadWriteLock.ExitReadLock threw an exception?
In #1, you'll call ReadWriteLock.ExitReadLock inappropriately. In #2, you may hide an existing exception that's been thrown (since finally clauses happen either because the mainline processing reached the end of the try block or because an exception was thrown; in the latter case, you probably don't want to obscure the exception). Perhaps both of those things are unlikely in this specific case, but you asked about the pattern, and as a pattern it has those issues.
Finally will be executed in any way, but for locking in may not be safe. Compare following methods:
class Program
{
static IEnumerable<int> meth1()
{
try
{
Console.WriteLine("Enter");
yield return 1;
yield return 2;
yield return 3;
}
finally
{
Console.WriteLine("Exit");
}
}
static IEnumerable<int> meth2()
{
try
{
Console.WriteLine("Enter");
return new int[] { 1, 2, 3 };
}
finally
{
Console.WriteLine("Exit");
}
}
static public void Main()
{
foreach (int i in meth1())
{
Console.WriteLine("In");
}
Console.WriteLine();
foreach (int i in meth2())
{
Console.WriteLine("In");
}
}
}
Output is:
Enter
In
In
In
Exit
Enter
Exit
In
In
In
If your processing takes much time (per iteration) it is more reasonable to fill collection first, then process, but not yield.
In Delphi I could do something like this:
try
if not DoSomething then
Exit;
if not DoSomething2 then
Exit;
if not DoSomething3 then
Exit;
finally
DoSomethingElse;
end;
In other means if method DoSomething results false then the program flow is transffered to the finally block and DoSomething2 and DoSomething3 are not executed.
How to achieve such behaviour in C#?
Thanks in advance.
Edit1:
The below example doesn't compile in VS 2008
Edit2: I am sorry I was to fast and forget the return statement;
XElement OrderStatus(q_order_status Request)
{
XElement Response;
try
{
if (DoSomething() != 0 )
{
return;
}
}
catch(Exception e)
{
// catch some errors and eventually pass the e.Message to the Response
}
finally
{
Response = new XElement("SomeTag", "SomeResponse");
}
return Response;
}
Edit3:
After testing it seems that the easiest way to achieve this is to throw an exception if the result of DoSomething1 is false. I can throw my own execption, write a specific message and pass it to the finally clause.
You really shouldn't be using exception handling constructs for flow control. That said, Exit is comparable to return in C#. As the MSDN Documentation about the [return keyword][1] says:
If the return statement is inside a try block, the finally block, if one exists, will be executed before control returns to the calling method.
In general a finally-block will almost always execute if the corresponding try-block has been reached. There are a few rare situations where it is impossible to guarantee that the finally-block executes, but they are all fatal errors, upon which programs should likely immediately crash.
How your code would look in C#:
try
{
if (!DoSomething())
return;
if (!DoSomething2())
return;
if (!DoSomething3())
return;
}
finally
{
DoSomethingElse();
}
But again, don't do this. try and finally are intended for handling exceptions, not for normal flow control.
Reply to your edit:
In your code return doesn't compile because the return type of the method is XElement and return by itself can only be used when the return type is void. You could use return new XElement("SomeTag", "SomeResponse");, as that is what the finally would be doing anyway, or you could assign Response earlier and do return Response;.
Note though that while the finally always executes, the return Response; that comes after it doesn't execute if the reason went into the finally-block is because you did a return inside the try-block.
Answer to updated question:
The reason you're having trouble doing this in an elegant way, is because you seem to be using a combination of return values and exceptions. You should consider manually raising an exception instead of using return values if the sitation is, well, exceptional.
Assuming there is a good reason for the return values however, I'm thinking it might be clearer to go without a finally block altogether, and to include a return at the end of the try block and also in your catch block. That would save you from passing the exception message in a messy way.
I can't really say what the best solution would be, since your code snippet does not show what Response would be if DoSomething() returns a non-zero value.
Original answer:
It depends a little on what you're trying to accomplish. Are exceptions actually being thrown in any of the methods? Otherwise there is no good reason to use a try-finally pattern. This would be equivalent (though maybe not advisable for readability):
bool doneEverything = DoSomething() && DoSomething2() && DoSomething3();
DoSomethingElse();
If there are exceptions being thrown, and handled at a higher level, I'd recommend isolating this code in a separate method, so you can use a return statement*.
void DoStuff()
{
try
{
if (!DoSomething())
return;
if (!DoSomething2())
return;
if (!DoSomething3())
return;
}
finally
{
DoSomethingElse();
}
}
To answer your question about when the finally code block is executed: it is always executed, unless the executing thread terminates prematurely.
*: Some restructuring is recommended, because there is no equivalent of the Delphi Exit. The break statement comes closest, but it can only be used in loop constructs or switch blocks. To mimic Exit behavior, you would need goto and a label. We wouldn't want that, now would we? :)
Why not make the three try-lines a common if/else block? Instead of exit, call the DoSomethingElse. Like so:
if (DoSomething() == false)
{
DoSomethingElse();
}
else if (DoSomething2() == false)
{
DoSomethingElse();
}
else if (DoSomething3() == false)
{
DoSomethingElse();
}
I would like to say that "C# is not Delphi", but that would be a bit arrogant.
In C#, finally is executed as well when return is called inside the try statement.
bool doSomething = false;
bool doSomething2 = true;
try
{
if( !doSomething )
{
Console.WriteLine ("not dosomething");
return;
}
if( !doSomething2 )
{
Console.WriteLine ("not dosomething 2");
return;
}
}
finally
{
Console.WriteLine ("In finally");
}
What about switch case of course If you don't mean the finally in c# by saying finally block. default case is the finally block then and you can also find flow control example and here at msdn : Flow Control (C# vs. Java)
static void Main(string[] args)
{
switch (args[0])
{
case "copy":
//...
break;
case "move":
//...
goto case "delete";
case "del":
case "remove":
case "delete":
//...
break;
default:
//...
break;
}
}
In this sort of situation, understanding the question as dealing exclusively with the non-exception handling case, I would refactor the contents of the try into a private helper method, like this
void BranchOnContext()
{
if (!DoSomething())
return;
if (!DoSomething2())
return;
// last one will drop out and return anyway
DoSomething3();
}
void DoStuff()
{
BranchOnContext(); // Assumed not to throw
DoSomethingElse(); // Always the next thing to be executed
}
EDIT -- tracking the changed requirement
void DoStuff()
{
string message = string.Empty;
try {
BranchOnContext();
} catch (MyExpectedException me) { // only catch exceptions I'm prepared to handle
message = me.Message;
}
DoSomethingElse(message); // Always the next thing to be executed
}
Taking another crack at this with the updated info:
I want DoSomethingElse to be executed
always and I want it to include
message from possible exception
If any of the DoSomething's return 0, null is returned. If not, the generic message is created. If there was an exception, it is caught and a message with its info is returned. How about this?
XElement OrderStatus(q_order_status Request)
{
try
{
if (DoSomething() != 0 )
{
return null;
}
else
{
return new XElement("SomeTag", "SomeResponse");
}
}
catch(Exception e)
{
// catch some errors and eventually pass the e.Message to the Response
return new XElement(e.tag, e.response);
}
}
Im still struggling with how to, in a good way, put finally into this.
I find it quite similar in behavior to the Delphi's one which I have shown on the beginning. I am interested in your comments. Response is dependent on the DoSomethings result.
XElement OrderStatus(q_order_status Request)
{
XElement Response;
int result = 0;
string Message = "";
try
{
result = DoSomething1();
if (result != 0)
{
throw new DoSomethingException("DoSomething1 has failed!");
}
result = DoSomething2();
if (result != 0)
{
throw new DoSomethingException("DoSomething2 has failed!");
}
result = DoSomething3();
if (result != 0)
{
throw new DoSomethingException("DoSomething3 has failed!");
}
Message = "All tests has been passed.";
}
catch(DoSomethingException e)
{
Message = e.Message;
}
catch(Exception e)
{
Message = e.Message;
}
finally
{
Response = new XElement("SomeTag", Message);
}
return Response;
}
What do you think?
void funcA()
{
if (!DoSomething())
return;
if (!DoSomething2())
return;
if (!DoSomething3())
return;
}
void funcB()
{
funcA();
DoSomethingElse;
}
This appears to replicate the delphi:-
try
{
if(DoSomething())
if(DoSomething2())
DoSomething3();
}
finally
{
DoSomethingElse();
}
an alternate style (some people will hate this style, others will love it.):-
try
{
DoSomething() && DoSomething2() && DoSomething3();
}
finally
{
DoSomethingElse();
}
I get the impression you want some other behaviour though?
Goto version?
try
{
if (!DoSomething())
goto Exit;
if (!DoSomething2())
goto Exit;
if (!DoSomething3())
goto Exit;
Exit:;
}
finally
{
DoSomethingElse();
}
Note the irritating ; after the label, it seems a label must precede a statement.
Just had an epiphany:-
Func<bool>[] somethings = new Func<bool>[] {DoSomething, DoSomething2, DoSomething3};
try
{
foreach (Func<bool> something in somethings)
{
if (!something())
break;
}
}
finally
{
DoSomethingElse();
}