If I illegally index into a list in the subscribed ClientSizeChanged() method, no ArgumentOutOfRangeException is thrown. Is this normal behavior ? And if so, when should I expect this behaviour ?

@ Roy T. : You're right in that it is an event which I'm subscribing to as follows :

game.Window.ClientSizeChanged += new EventHandler<EventArgs>(Window_ClientSizeChanged);

and here's my event handler addendum (sorry, I don't know how to properly talk about these things) :

    // Event manager that responds to the window size being changed
    private static void Window_ClientSizeChanged(object sender, EventArgs e)
        presentationRegion = GDM.GraphicsDevice.PresentationParameters.Bounds;
        if (currentScreen <= 0 || currentScreen > screens.Count)
            throw new Exception("currentScreen index is out of bounds of the screen list");

        List<int> myIntList = new List<int>();
        myIntList[-2] = 7; // Exception is not thrown here

        screens[currentScreen - 1].UpdateLayout();
        //Game.Window.Title += " WinCSC | ";

I've put in the integer List just to demonstrate the effect. Although I originally noticed it with the screens[currentScreen-1].UpdateLayout() call.

@ Blecki : You are onto it I think. So when I trace the execution, as soon as i index into myIntList with an index of -2 execution breaks out of Window_ClientSizeChanged() and the exception is not caught. And even if I throw my own exception inside Window_ClientSizeChanged() the application continues without the debugger catching it.

  • 1
    \$\begingroup\$ What list and method are you talking about? Could you show a small piece of code? All I could find is the msdn.microsoft.com/en-us/library/… event which is not a method but an event. \$\endgroup\$ – Roy T. Oct 9 '11 at 17:51
  • 1
    \$\begingroup\$ Looking at the GameWindow class with Reflector doesn't show anything strange. Are you sure you are accessing an illegal position? \$\endgroup\$ – r2d2rigo Oct 9 '11 at 19:26
  • 1
    \$\begingroup\$ I'm going to guess that whatever calls clientSizeChanged() is catching the exception. The debugger never notices because it's handled. Have you broken into the function and confirmed that no exception is being thrown? Or ClientSizeChanged() is being called by a different thread. If that's the case, it's throwing an exception, but the debugger can't catch it. \$\endgroup\$ – Blecki Oct 10 '11 at 2:23
  • \$\begingroup\$ Note that it's impossible to "disable exceptions" in managed code -- at best a piece of code can suppress them with a no-op catch block (but they are still thrown). Debuggers can always be configured to trap or break on them (although it's not always a simple configuration). \$\endgroup\$ – Josh Oct 10 '11 at 15:51

You should check out this question and my answer to it. I think you may be getting bit by the same issue, specifically the fact that in 64-bit Windows, exceptions that reach the managed/native transition boundary are quietly swept under the rug, never to be seen again.

This occurs most often in event callbacks for Windows Forms and other wrapper APIs that occur in response to Win32 messages, such as HWNDs being constructed (the Windows Forms Load event) or resized (possibly the client-size-changed event you are trying to hook now).

As I noted in my other answer, there's a detailed explanation of this behavior here.

  • \$\begingroup\$ Thanks Josh and everyone else for your helpful suggestions. And thanks for the links Josh. This explanation seems very applicable. \$\endgroup\$ – Gavin Williams Oct 10 '11 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.