tags:

views:

60

answers:

3

Can I detect at runtime inside method Helper() that the program execution is the result of a thrown exception?

Note, my goal is to avoid extending method Helper() to take an exception object as a input pararmeter.

public void MyFunc1()
{
  try
  {
    // some code here that eventaully throws an exception
  }
  catch( Exception ex )
  {
     Helper();
  }
}

public void MyFunc2()
{
   Helper();
}

private void Helper()
{
    // how can I check if program execution is the  
    // result of a thrown exception here.
}
+3  A: 

I cannot think of any reason why you wouldn't do it like this:

private void Helper(bool exceptionWasCaught)
{
    //...
}
Hans Passant
In a perfect world I agree; however, my example simplifies my situation, I am trying to avoid changing the signature of the Helper method.
Zamboni
StackFrame class: nah. No way to find out if an exception is being handled. Global variable.
Hans Passant
Thanks, I agree with your answer, the idea for my question came to me when I was few layers deep in code and I did not want to change the method signatures. In the end I decided to change the signatures given the answers I got.
Zamboni
That was a good move.
Hans Passant
+2  A: 

Not that I'm aware of. This is cumbersome, but it fully delineates you as the developer's intent:

private bool inException = false;

public void MyFunc1()
{
  try
  {
    inException = false;

    // some code here that eventaully throws an exception
  }
  catch( Exception ex )
  {
     inException = true;
     Helper();
  }
}

public void MyFunc2()
{
   inException = false;
   Helper();
}

private void Helper()
{
    // how can I check if program execution is the  
    // result of a thrown exception here.
    if (inException)
    {
        // do things.
    }
}
Jesse C. Slicer
Sorry, but this is very bad design and I would never suggest code like that! Please people, dont use this code! Take "Hans Passant" Version or better pass the exception instead of a boolean.
Scordo
In a perfect world I agree; however, my example simplifies my situation, I am trying to avoid changing the signature of the Helper method. – Zamboni 2 mins ago
DeadMG
@Scordo: I went out of my way to say it wasn't that great. Many times people inherit code in which the methods can't have their signatures changed easily like that. I agree with Hans' way, no doubt. If you can show a solution with minimal invasiveness to method signatures that is cleaner, please contribute.
Jesse C. Slicer
@Zamboni: I'm not changing method signatures. In fact, I specifically am **not** as per your comment to Hans.
Jesse C. Slicer
+1 simply because this is just about the only thing that answers the original question without modifying the signature of `Helper`. Yes, it's horrible, but only because the question is already horrible (for catching `Exception`).
Daniel Earwicker
Thanks for your the answer, this is a good solution.
Zamboni
+3  A: 

There is one horrible hack involving Marshal.GetExceptionPointers and Marshal.GetExceptionCode that doesn't work on all platforms here it is:

public static Boolean IsInException()
{
   return Marshal.GetExceptionPointers() != IntPtr.Zero ||
          Marshal.GetExceptionCode() != 0;
}

From this page: http://www.codewrecks.com/blog/index.php/2008/07/25/detecting-if-finally-block-is-executing-for-an-manhandled-exception/

jdehaan
+1/2 for crazy solution and +1/2 for saying its a horrible hack
Simon_Weaver
That only works for exceptions that started life as a Windows SEH exception. Like NullReference or AccessViolation.
Hans Passant
Thanks for the precision Hans. And thanks for the half points Simon. I think there is another "cleaner" hack involving the inspection of the stack frames, but I need to sleep, I'll try it out another time :-).
jdehaan
Thanks, this is the most correct answer given the question I asked.
Zamboni
Whoa, it's not. Getting something out of GetExceptionCode() is the exception.
Hans Passant