finally block

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

Once the execution enters the "finally" block, the execution could have
followed

1. normal/non-exception execution. (I guess everyone knows what I mean here.)
2. Exception was thrown, and handled.
3. Unhandled exception.

Is there a way to find out which of above three has happened while in
"finally" block? In specific, I would like to know whether the execution is
in "unhandled" exception state or "others (don't care to distinguish between
1 and 2)" state.

Thanks,
 
George,
Is there a way to find out which of above three has happened while in
"finally" block?
Click to expand...

Nothing built into the language, but you could keep track of that
yourself by setting some flag. But if you need this, it sounds like
you've got a design problem.


Mattias
 
George said:
Hi,

Once the execution enters the "finally" block, the execution could have
followed

1. normal/non-exception execution. (I guess everyone knows what I mean here.)
2. Exception was thrown, and handled.
3. Unhandled exception.

Is there a way to find out which of above three has happened while in
"finally" block? In specific, I would like to know whether the execution is
in "unhandled" exception state or "others (don't care to distinguish between
1 and 2)" state.

Thanks,
Click to expand...

Easiest way is to declare a couple of bools.

bool exThrown, exHandled

try
//some exception-throwing code
catch (Exception ex)
{
exThrown = true;
//try to handle
//if you handle it successfully...
exHandled = true;
//otherwise...
exHandled = false;
throw ex;
}
finally
{
//decide what to do based on the values of exThrown and exHandled
}

You should know which specific exceptions you can successfully handle
and catch those in specific clauses. If you ever have to rethrow, make
sure exHandled is false. Besides the specific exceptions, catch any
other Exceptions that are thrown in a catch-all, set exThrown to true,
then immediately rethrow. Finally will then know two things; whether an
exception was thrown, and whether it was completely handled.

You could also put the case-specific code where it would only be
executed under the conditions you want. Put the code that should
execute when no exception is thrown at the very end of the try block,
put code that should happen when you handle an exception at the end of
the catch handler, put code for unhandled exceptions in a catch-all and
then rethrow, and put code that should execute regardless of the
situation in the finally block.
 
As was mentioned before, you shouldn't need to write code to find out
what's about to happen when you leave finally. Finally is for code that
should happen no matter what, such as destroying objects and
Datareaders that, no matter what you're doing next, you don't need and
want garbage collection to clear from memory.
 
Hi,

Thanks for the input.

I don't really need this capability in the language, however, I do think
that it will simplify my code. I do not think the need to use it is a design
issue either.

If you take a look of the following 2 methods:

1. MyFunction_A() is the original code and MyFunction_B() "untilizes" the
ability to know whether the execution is in "unhandled" state. Of course,
this ability does not exist.

2. CleanUp() is called if the
a. animal is a monkey
b. when exception is not handled, or will be rethrown.

public void MyFunction_A()
{
...

try
{
...


if (typeOfAnimal == Animal.Monkey)
{
CleanUp();
}

}
catch (JobUtils.AutomationException ex)
{
CleanUp();
throw (ex);
}
catch (Exception ex)
{
CleanUp();
throw (ex);
}
return;
}

public void MyFunction_B()
{
...

try
{
...
}
catch (JobUtils.AutomationException ex)
{
throw (ex);
}
catch (Exception ex)
{
throw (ex);
}
finally
{
if (typeOfAnimal == Animal.Monkey || <Unhandled exception state>)
{
CleanUp();
}
}

return;
}
 
George said:
Once the execution enters the "finally" block, the execution could have
followed

1. normal/non-exception execution. (I guess everyone knows what I mean
here.)
2. Exception was thrown, and handled.
3. Unhandled exception.

Is there a way to find out which of above three has happened while in
"finally" block? In specific, I would like to know whether the execution
is
in "unhandled" exception state or "others (don't care to distinguish
between
1 and 2)" state.
Click to expand...

Don't really understand why you need to do it, but maybe something like
this:


System.Exception Exception = null;
try {
...
} catch (System.NullReferenceException Ex) {
Exception = Ex;
} catch (System.ArgumentException Ex) {
Exception = Ex;
} finally {
if (Exception != null) {
if (Exception is System.NullReferenceException) ...
else if (Exception is System.ArgumentException) ...
else ...
}
}



-- Alan
 
Hi George,

Thanks for your feedback!

Yes, I understand your concern. As I think, providing the information of
whether current code is coming from an exception or normal execution path
at language level is useful . I am not sure why this feature is not
provided in C# language. I will help you to consult it in our C# team.

Currently, I think the simplest solution to this problem is using bool
flags in all the possible execution paths. Below code snippet demonstrates
this:

private void method()
{
bool fNormal=false, fCatch=false, fUnhandled=false;
try
{
...
fNormal=true; //just before exiting the try clause
}
catch(Specific Exception)
{
fCatch=true;
...
}
finally
{
if(fNormal)
{
...
}
else if(fCatch)
{
}
else
{
fUnhandled=true;
}
}
}
Does this meet your need? If I misunderstand you, please feel free to tell
me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi George,

Sorry for letting you wait.

After discussing internally, I was told that since few developers require
this feature, so the system is not burdened with setting up flags which
rarely are used. I think the bool flag workaround is the suitable for your
scenario. Does it meet your need? Please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top