0

I've recently inherited a C# (.NET 4.0) project at work. The project is 400k+ lines of code and uses many large, large try/catch blocks that catch any Exception. Occasionally, the application throws an IndexOutOfRangeException, and my boss has asked me to attempt to find an easy way to uncover the name of the array that threw the exception. (Such large try/catch blocks can contain many arrays.) I know that I can use the FirstChanceException event to trigger code to execute when the IndexOutOfRangeException is thrown. For example:

class ExceptionTest
{
    public static void Main()
    {
        AppDomain.CurrentDomain.FirstChanceException
+= new EventHandler<FirstChanceExceptionEventArgs>(CurrentDomain_FirstChanceException);
        int[] arr = new int[0];
        arr[0] = 0;
        Console.Read();
    }

    static void CurrentDomain_FirstChanceException(object sender, 
FirstChanceExceptionEventArgs e)
    {
        if (e.Exception.GetType() == typeof(IndexOutOfRangeException))
        {
            Console.WriteLine(e.Exception.StackTrace);
        }
    }
}

Unfortunately, I can't seem to find the problematic array's name in this manner, but combing through 400k+ lines of code isn't an option.

I personally don't understand the point of this task, but I would appreciate any help. Is this even possible?

EDIT: 5. August 2014

I should clarify: it's very easy to find the problematic arrays when debugging in VS. The point of this task is to discover which arrays throw exceptions when the release build of the program is being used by our clients. The program uses a set of log files, but these files only indicate the type of exception that is thrown - not the array name or line number.

Community
  • 1
  • 1
wisner
  • 523
  • 1
  • 5
  • 18
  • 2
    Cannot you analyze the exception stack to see where the problem occurred? – AlexD Jul 31 '14 at 21:59
  • The stack trace is *definitely* the way forward here. It should show you the line containing the error. There could be multiple array accesses on the same line, admittedly. – Jon Skeet Jul 31 '14 at 22:00
  • If possible, rebuild and deploy the debug symbols with the assembly. Then analyze the stack trace from the exception. – EkoostikMartin Jul 31 '14 at 22:02
  • Cross your fingers that the `catch` blocks don't contain `throw ex` (or whatever your Exception variable is named), as you'll lose the stack trace. – dyson Jul 31 '14 at 22:03
  • Do you have pdb files available at runtime? – Mare Infinitus Jul 31 '14 at 22:04
  • What are you doing in these try-catch blocks? Are you handling the exception, wrapping them, or re-throwing them? If you can debug, add Debugger.Break(); – jtimperley Jul 31 '14 at 22:04
  • If you're debugging with Visual Studio, use `Debug`->`Exceptions`->`Common Language Runtime Exceptions`-> Check the `Thrown` box. This will break your program right when the Exception occurs, regardless of whether it's caught. – Alex Jul 31 '14 at 22:05
  • Please see edit. The arrays are to be determined at runtime of the release build. Is there any way to record the line number with the stack-trace? – wisner Aug 05 '14 at 12:48

2 Answers2

1

use this code

try
{
    //large number of arrays in you code like
    int[] arr1;
    int[] arr2;
    //these type of codes and declerations
}
catch(Exception e)
{
    Console.WriteLine(e.Message + "  " + e.StackTrace);
}

Now this StackTrace will show you on which line number, there is the error in your code

ARK
  • 229
  • 1
  • 11
0

I have discovered with much thought, research, and experimentation that what is described is not possible. Yes, I could obtain in the line number, but unfortunately, there are so many different versions of the compiled application distributed that the code is very dynamic and a line number would be meaningless.

wisner
  • 523
  • 1
  • 5
  • 18
  • 1
    Sounds like the release process needs some improvement if it's impossible to determine what code has been distributed to whom. – Lukazoid Aug 14 '14 at 21:05