Nested exceptions

  • Thread starter Thread starter nickdu
  • Start date Start date
N

nickdu

Can't think of a better subject for this. What I would like to know is if
the following will do what I'm hoping it will do:

try
{
...
}
catch(Exception)
{
try
{
EventLog.WriteEntry(...);
}
catch(Exception)
{
}
throw;
}

Here I would like to write an event to the NT event log in the case of an
error. However if I fail writing the NT event log, maybe because my event
source is not registered, I don't want to lose the original exception that
caused the error. Will the throw; statement still throw the original
exception even if EventLog.WriteEntry() causes an exception?
--
Thanks,
Nick

(e-mail address removed)
remove "nospam" change community. to msn.com
 
Add your throw statement in finally block which will ensure that it will get
executed always whenever you are throwing the parent exception irrespective
of the fact whether your event log entry is successful or not.
 
So you're saying to move the throw from the catch block to a finally block?
But then it will look as if no exception occurred, correct?
--
Thanks,
Nick

(e-mail address removed)
remove "nospam" change community. to msn.com
 
Updated code:
===============

try
{
...
}
catch(Exception)
{
try
{
EventLog.WriteEntry(...);
}
catch(Exception)
{
}
finally
{
throw;
}
}
 
Shekhar said:
Updated code:
===============

try
{
...
}
catch(Exception)
{
try
{
EventLog.WriteEntry(...);
}
catch(Exception)
{
}
finally
{
throw;
}
}
Click to expand...
This isn't legal. You can't use a parameterless "throw" statement in a
nested finally block. You'd have to name your exception and rethrow it
explicitly (overwriting the stack in the process).

Putting the "throw" outside the "finally" will work just as well, since
you've wrapped the rest in an exception handler anyway. Putting the whole
thing in a new method (that's explicitly documented to never fail) is an
even better idea.
 
Good catch n sorry for the ignorance.


Jeroen Mostert said:
This isn't legal. You can't use a parameterless "throw" statement in a
nested finally block. You'd have to name your exception and rethrow it
explicitly (overwriting the stack in the process).

Putting the "throw" outside the "finally" will work just as well, since
you've wrapped the rest in an exception handler anyway. Putting the whole
thing in a new method (that's explicitly documented to never fail) is an
even better idea.
Click to expand...
 
Hello Nick,

Jeroen is right. We need to name the first exception and throw it
explicitly. Based on the description of you requirement. I have tested the
following code structure. Please let me know if it fits your demand. Any
future questions or concerns, please feel free to let me know. I will try
my best to follow up.
try
{
throw new Exception("test"); //mimic an exception
}
catch (Exception ex)
{
try
{
throw new Exception("test2"); //mimic the event log
exception
EventLog.WriteEntry("MyApp",ex.Message);
}
catch
{
throw ex;
}
}

Have a good day!

Best regards,
Ji Zhou ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

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://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
I definitely don't want this solution as it's invalid. You should never use
throw(e) to rethrow an exception as the stack trace will be wiped out and
regenerated and thus invalid to the error. If you're using the parameterized
throw to throw the original exception you should always be chaining it to a
new exception.

That being said I think I'll go with the parameterless throw and use it
after the inner catch block as based on Jeroen's post it should work just
fine.
--
Thanks,
Nick

(e-mail address removed)
remove "nospam" change community. to msn.com
 
Back
Top