Re: [msvc] IOCP

[Max]

HI   Every exception under MSVC (C++ exceptions, and Win32 Structured Exceptions) is raised using the Kernel32 function RaiseException.  This function checks to see if a debugger is present (IsDebuggerPresent( )).  If one's present, it informs the debugger before raising the exception.  The debugger then can notify you, and this is called a first chance notification.   Yup.     Usually, at this stage, debuggers ask you whether you want to pass the exception to the debugee.  If you say no, then the debugee program will not be able to catch the exception.  After this, RaiseException goes on to actually raise (throw) the exception by searching in the list of exception handlers registered for the current thread.  If no handler capable of handling the exception is found, the program will be terminated by the OS, or you will get a second chance notification if the program is being debugged.  Now, if an exception is thrown and handled gracefully, then you won't get any second chance notification, and because the debugger is by default set not to notify first chance notifications, you won't notice anything.    If you look at the 'Output Window' you will see first chance exceptions being thrown.  A lot of the time this is handled by the OS and the OS may have cause the First chance exception, however I know that the thing being thrown is my fault and not something the OS is doing, however it doesn't crash - as I would expect... (more later)    If no handler is found, the second chance notification is raised, and you'll know that you're having something we know as an unhandled exception.  If you configure the debugger to notify you on first chance notifications, then you will be notified every time RaiseException is called.  Generally, in that case, if you don't get a second chance exception, your app has not actually crashed.    Yeah, I understand this and it helped as I've had more than one exception problem (more later)....      That means that an exception had been thrown and handled gracefully.  There are functions which actually rely on throwing an exception and catching it for correct functioning - for those, this first chance notification is safe.    Yup, Yup - but this isn't one of them (more later)    However, other functions might encounter exceptions because you're doing something wrong (e.g. pass them a wrong parameter) albeit they handle it gracefully; for those functions, a first chance exception is a sign of something fishy going on.     Thats what I'm seeing now....   So, the short story is that first chance notifications are not a sign of hazard by themselves.     True - however let me explaine some more....     I've found a few minor problems with what I'm doing.  The first was a "crash" (exception) - however it only showed up while running the program under the debugger.  If you ran the program normally - either the debug or release version it worked fine.  I found the problem by breaking on the first chance exception and then I found I was using a pointer that had not been zeroed so I was using a bad pointer - however the program didn't crash but the ("crash") problem showed up the next time I tried to allocate memory in a different thread.     The second problem - where I know the first chance exception that happening is my fault however it still works...   Heres a bit of background   I'm using IOCP so I have a callback and I have wrapped up my Connection to other machines etc in a Connection class   Callback (DWORD dwError, dwNumberOfBytes, LPOVERLAPPED lpOverLapped) {         Use the lpOverlapped     OVERLAPPEDPLUS * pOverlapped = (OVERLAPPEDPLUS*) lpOverlapped;     CConnection * pConnection = 0;         if (pOverlapped)     {         if (pConnection)         {                // Do something.         }         } }   CConnection { OVERLAPPEDPLUS : public Overalpped {     pConnection = this;     bool bOperation;  }     }     Now when someone disconnects the CConnection its freed from memory, this disconnection seems to cause the IOCP to complete immediately.  So the callback gets called again.  The problem I'm having is that the pOverlapped pointer seems to be valid however the pConnection pointer contains junk - ( I freed the memory it points to) , so when I try to 'Do Something' with the pointer it cause the first chance exception.  Now since the app doesn't crash and I only get a first chance exception I'm assuming that the OS catches it...   However I don't like this assumption so I just wanted to find a way to make sure I didn't use a duff pointer..   Regards Max