Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. MFC Exceptions

MFC Exceptions

Scheduled Pinned Locked Moved C / C++ / MFC
data-structureshelpquestionc++database
9 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    rrrado
    wrote on last edited by
    #1

    I'm using CArray - derived classes in my app. I have bug somewhere I cannot reproduce, I think it could be accessing CArray by index out of range (but I'm not sure). When I do so, default implementation CWinApp::ProcessWndProcException() displays the "An invalid argument was encountered." and after confirming program continues which is bad. What I need to do is to make my program to crash, because I have exception handler in my app which creates and sends crash dump to me and I need to see which access to array caused the exeption. How can I disable default CException* handler? I've overriden my ProcessWndProcException() and put THROW_LAST and also just "throw" but it didn't help. Message box was not displayed but nothing happened, program does not crash. Putting "int 3" into handler does not help, because it crashes but I cannot see in stack trace where was bad access to the array, just useless exception hadler. Any idea what could I do? I don't want to add try/catch to each array access, there are dozens of that in program :( Thank you.

    S 1 Reply Last reply
    0
    • R rrrado

      I'm using CArray - derived classes in my app. I have bug somewhere I cannot reproduce, I think it could be accessing CArray by index out of range (but I'm not sure). When I do so, default implementation CWinApp::ProcessWndProcException() displays the "An invalid argument was encountered." and after confirming program continues which is bad. What I need to do is to make my program to crash, because I have exception handler in my app which creates and sends crash dump to me and I need to see which access to array caused the exeption. How can I disable default CException* handler? I've overriden my ProcessWndProcException() and put THROW_LAST and also just "throw" but it didn't help. Message box was not displayed but nothing happened, program does not crash. Putting "int 3" into handler does not help, because it crashes but I cannot see in stack trace where was bad access to the array, just useless exception hadler. Any idea what could I do? I don't want to add try/catch to each array access, there are dozens of that in program :( Thank you.

      S Offline
      S Offline
      Stuart Dootson
      wrote on last edited by
      #2

      What you want to do is to run your app under the debugger and get the debugger to break when an exception is thrown (the Debug->Exceptions menu item (IIRC) opens a dialog that allows you to do this.

      Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

      R 1 Reply Last reply
      0
      • S Stuart Dootson

        What you want to do is to run your app under the debugger and get the debugger to break when an exception is thrown (the Debug->Exceptions menu item (IIRC) opens a dialog that allows you to do this.

        Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

        R Offline
        R Offline
        rrrado
        wrote on last edited by
        #3

        I do not want to run it in debugger, I want it to run at customer's computer and send me the correct crash report (currently working for unhandled non-CException exceptions)

        S 1 Reply Last reply
        0
        • R rrrado

          I do not want to run it in debugger, I want it to run at customer's computer and send me the correct crash report (currently working for unhandled non-CException exceptions)

          S Offline
          S Offline
          Stuart Dootson
          wrote on last edited by
          #4

          OK - here's a thought... I'm presuming you're using CArray code in afxtempl.h. This calls AfxThrowInvalidArgException() to throw the exception you're seeing. Why not use a #define to change what AfxThrowInvalidArgException means? If we use this articles[^] code to provide a stackwalker, you could do something like this #define (put it in your code BEFORE you #include afxtempl.h)

          #define AfxThrowInvalidArgException() { StackWalker sw; sw.ShowCallstack(); AfxThrowInvalidArgException(); }

          You'd need to add something to change how the stack trace is displayed, and also distribute dbghelp.dll with your app, but I think it could help you?

          Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

          R 2 Replies Last reply
          0
          • S Stuart Dootson

            OK - here's a thought... I'm presuming you're using CArray code in afxtempl.h. This calls AfxThrowInvalidArgException() to throw the exception you're seeing. Why not use a #define to change what AfxThrowInvalidArgException means? If we use this articles[^] code to provide a stackwalker, you could do something like this #define (put it in your code BEFORE you #include afxtempl.h)

            #define AfxThrowInvalidArgException() { StackWalker sw; sw.ShowCallstack(); AfxThrowInvalidArgException(); }

            You'd need to add something to change how the stack trace is displayed, and also distribute dbghelp.dll with your app, but I think it could help you?

            Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

            R Offline
            R Offline
            rrrado
            wrote on last edited by
            #5

            Thank you for idea, I was now going to create some CArrayEx template which would derive from carray and add AfxThrowInvalidArgException() as member function which would just throw -1 or something. Macro approach is faster so I'm going to give it a try. Still it looks to me weird why rethrowed CException just disappeared and didn't crash the app. When I was tracing my (re)throw in debugger, it wanted to go to some throw.cpp file but didn't have a source.

            1 Reply Last reply
            0
            • S Stuart Dootson

              OK - here's a thought... I'm presuming you're using CArray code in afxtempl.h. This calls AfxThrowInvalidArgException() to throw the exception you're seeing. Why not use a #define to change what AfxThrowInvalidArgException means? If we use this articles[^] code to provide a stackwalker, you could do something like this #define (put it in your code BEFORE you #include afxtempl.h)

              #define AfxThrowInvalidArgException() { StackWalker sw; sw.ShowCallstack(); AfxThrowInvalidArgException(); }

              You'd need to add something to change how the stack trace is displayed, and also distribute dbghelp.dll with your app, but I think it could help you?

              Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

              R Offline
              R Offline
              rrrado
              wrote on last edited by
              #6

              #define approach does not work. It is ignored and I'm still getting old exception. I'm afraid I'll have to create my own template for CArray or redesign all the code to std::vector :(( :((

              S 2 Replies Last reply
              0
              • R rrrado

                #define approach does not work. It is ignored and I'm still getting old exception. I'm afraid I'll have to create my own template for CArray or redesign all the code to std::vector :(( :((

                S Offline
                S Offline
                Stuart Dootson
                wrote on last edited by
                #7

                rrrado wrote:

                redesign all the code to std::vector

                Not such a bad idea - I gave up on CArray over 10 years ago, when I was using VC5 (which was even shonkier with templates than VC6).

                Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

                1 Reply Last reply
                0
                • R rrrado

                  #define approach does not work. It is ignored and I'm still getting old exception. I'm afraid I'll have to create my own template for CArray or redesign all the code to std::vector :(( :((

                  S Offline
                  S Offline
                  Stuart Dootson
                  wrote on last edited by
                  #8

                  If I'd thought a bit more, I'd have realised that could never work for various reasons. However, this suggestion does let you intercept AfxThrowInvalidArgException:

                  1. BEFORE you #include any MFC headers (so put this in your stdafx.h), add this:

                    #define AfxThrowInvalidArgException MyThrowInvalidArgException

                  2. Now add this code at the end of one of your .cpp files, changing the body to suit what you want to do

                    void __stdcall MyThrowInvalidArgException()
                    {
                    // Whoops!
                    #undef AfxThrowInvalidArgException
                    OutputDebugString(_T("WHOOPS"));
                    void __declspec(noreturn) AFXAPI AfxThrowInvalidArgException();
                    AfxThrowInvalidArgException();
                    }

                  I've tried this under VS2008 with a simple MFC app and MyThrowInvalidArgException was called when I executed this code:

                  CArray<int, int> arr;
                  arr.GetAt(100);

                  Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

                  R 1 Reply Last reply
                  0
                  • S Stuart Dootson

                    If I'd thought a bit more, I'd have realised that could never work for various reasons. However, this suggestion does let you intercept AfxThrowInvalidArgException:

                    1. BEFORE you #include any MFC headers (so put this in your stdafx.h), add this:

                      #define AfxThrowInvalidArgException MyThrowInvalidArgException

                    2. Now add this code at the end of one of your .cpp files, changing the body to suit what you want to do

                      void __stdcall MyThrowInvalidArgException()
                      {
                      // Whoops!
                      #undef AfxThrowInvalidArgException
                      OutputDebugString(_T("WHOOPS"));
                      void __declspec(noreturn) AFXAPI AfxThrowInvalidArgException();
                      AfxThrowInvalidArgException();
                      }

                    I've tried this under VS2008 with a simple MFC app and MyThrowInvalidArgException was called when I executed this code:

                    CArray<int, int> arr;
                    arr.GetAt(100);

                    Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

                    R Offline
                    R Offline
                    rrrado
                    wrote on last edited by
                    #9

                    Thank you very much for your time. I've made it to work with macro, but modified, I hope it will help me.

                    1 Reply Last reply
                    0
                    Reply
                    • Reply as topic
                    Log in to reply
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • World
                    • Users
                    • Groups