|
George_George wrote: ...we use try/catch, we are still dealing with structured exception...
Not according to everything that I've read on the subject. Microsoft's __try /__catch is SEH.
Perhaps you should read this.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Yes, DavidCrow.
What I do not agree with you is you mentioned when there is structured exception, during stack unwinding, the local object's destructor is not called.
Through my experiment, it is not true.
You can try the following code and see if structured exception occurs, like access violation, during stack unwinding, destructor is also called.
So the question can be asked in two ways,
1. Why __try/__except does not work with structured exception with destructor;
2. Why try/catch work with structured exception with destructor.
Now we are talking about (2).
#include <iostream>
#include <excpt.h>
#include <windows.h>
using namespace std;
class Foo
{
public:
Foo()
{
cout << "constructing Foo" << endl;
}
virtual ~Foo()
{
cout << "destrucing Foo" << endl;
}
};
int main()
{
int* address = NULL;
try{
Foo foo1;
(*address) = 1024;
} catch (...)
{
cout << "access violation caught" << endl;
}
return 0;
}
</windows.h></excpt.h></iostream>
regards,
George
|
|
|
|
|
Okay.
SEH is different from C++ exception.__try __catch block indicates that this is a SEH, and try catch indicates that this is a C++ exception.
MSDN said that :in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled.
where asynchronous exception is SEH. In your code, Foo's destructor will not be called, so compiler generates an error. If you comment this line cout << "destrucing Foo" << endl; int Foo's destructor, and your code will be compiled.
A Chinese VC++ programmer
|
|
|
|
|
Great, zengkun100!
1.
zengkun100 wrote: Foo's destructor will not be called, so compiler generates an error. If you comment this line cout << "destrucing Foo" << endl; int Foo's destructor, and your code will be compiled.
No. You can try to comment out the statements in destructor and the compiler error still exists.
2.
try/catch can catch structured exception, in my case, access violation is not a C++ exception and is a structured exception, agree? But try/catch can catch it and calling destructor, unwinding stack quite well.
You can try (2) by changing my sample from __try to try and __except to catch(...).
regards,
George
|
|
|
|
|
I don't know which compiler you use.
My IDE is VS2008 beta 2, after I commented the line, the program compiled successfully.MSDN said that
<br />
Specifies the model of exception handling to be used by the compiler and destroys C++ objects that will go out of scope as a result of the exception. If /EH is not specified, the compiler will catch structured and C++ exceptions, but will not destroy C++ objects that will go out of scope as a result of the exception.<br />
<br />
<br />
/EH{s|a}[c][-]<br />
<br />
<br />
Arguments<br />
a<br />
The exception-handling model that catches asynchronous (structured) and synchronous (C++) exceptions.<br />
<br />
s<br />
The exception-handling model that catches C++ exceptions only and tells the compiler to assume that extern C functions do throw an exception.<br />
<br />
c <br />
If used with s (/EHsc), catches C++ exceptions only and tells the compiler to assume that extern C functions never throw a C++ exception. /EHca is equivalent to /EHa.<br />
<br />
Remarks<br />
Use /EHs to specify the synchronous exception handling model (C++ exception handling without structured exception handling exceptions). If you use /EHs, then your catch clause will not catch asynchronous exceptions. Also, in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled. Under /EHs, catch(...) will only catch C++ exceptions. Access violations and System..::Exception exceptions will not be caught.<br />
<br />
Use /EHa to specify the asynchronous exception handling model (C++ exception handling with structured exception handling exceptions). /EHa may result in a less performant image because the compiler will not optimize a catch block as aggressively, even if the compiler does not see a throw.<br />
<br />
Use /EHa if you want to catch an exception raised with something other than a throw. The following sample will generate an exception:<br />
<br />
Copy Code <br />
#include <iostream><br />
#include <excpt.h><br />
using namespace std;<br />
<br />
void fail() {
try {<br />
int i = 0, j = 1;<br />
j /= i;
}<br />
catch(...) {
cout<<"Caught an exception in catch(...)."<<endl;<br />
}<br />
}<br />
<br />
int main() {<br />
__try {<br />
fail(); <br />
}<br />
<br />
__except(EXCEPTION_EXECUTE_HANDLER) { <br />
cout << "An exception was caught in __except." << endl;<br />
}<br />
}<br />
<br />
<br />
</excpt.h></iostream>
And access violation is called hard exception, NOT structured exception. I have said that __try __catch block indicates a structured exception.
Jeffery Richter's great book «Programming Applications for Microsoft Windows»has a good explanation about SEH
A Chinese VC++ programmer
|
|
|
|
|
Thanks zengkun100,
Your reply is great!
Two more comments,
1.
zengkun100 wrote: Use /EHs to specify the synchronous exception handling model (C++ exception handling without structured exception handling exceptions). If you use /EHs, then your catch clause will not catch asynchronous exceptions. Also, in Visual C++ 2005, all objects in scope when the asynchronous exception is generated will not be destroyed even if the asynchronous exception is handled. Under /EHs, catch(...) will only catch C++ exceptions. Access violations and System..::Exception exceptions will not be caught.
It means under /EHs mode, structured exception still exists, but we can not catch it and destructor of local object is not called during structured exception triggered stack unwinding. Right?
BTW: but I have proved it is not true. I have posted my sample below and if you compile with /EHsc and you can see the output is -- means destructor is still called during stack unwinding, not the same as the above statement from MSDN.
--------------------
constructor
destructor
--------------------
2.
I have wrote some code to verify that when using /EHa, during exception triggered stack unwinding, the destructor of local object is invoked. Could you help to review my code to see whether both my conclusion and the code are correct please?
#include <iostream>
using namespace std;
class Foo
{
public:
Foo()
{
cout << "constructor" << endl;
}
virtual ~Foo()
{
cout << "destructor" << endl;
}
};
int main ()
{
int i = 1;
int j = 0;
try{
Foo foo;
i = i / j;
} catch (...)
{
cout << "catch structured exception -- division by zero" << endl;
}
}
My output:
--------------------
constructor
destructor
catch structured exception -- division by zero
--------------------
have a good weekend,
George
|
|
|
|
|
this occurs while iam trying to use domodal()
only in debug mode..
it works fine in release mode. help me to get rid of this...
|
|
|
|
|
If it happens in debug mode, then have you tried debugging it? Work backwards from the exception, and find out what wrong information you're giving to MFC?
Iain.
|
|
|
|
|
Maybe posting the code where exception happens will help.
I can guess it is an ASSERT though.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Its in appcore.cpp
// CWinApp diagnostics
#ifdef _DEBUG
void CWinApp::AssertValid() const
{
CWinThread::AssertValid();
ASSERT(afxCurrentWinApp == this);
ASSERT(afxCurrentInstanceHandle == m_hInstance);
if (AfxGetThread() != (CWinThread*)this)
return; // only do subset if called from different thread
if (m_pDocManager != NULL)
ASSERT_VALID(m_pDocManager);
}
|
|
|
|
|
As you can see, you don't get an exception on release version, because the code is inside
_DEBUG guard (BTW ASSERT itsef is guarded by _DEBUG ).
Anyway it seems your application's m_Instance has not the proper value, maybe you have to check its value with the debugger.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Neels wrote: it works fine in release mode.
No, it only APPEARS to work. The problem exists in both, but because of the differences in the way each is compiled, variables are initialized, etc, the problem has simply been moved or masked.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi,
I have installed global mouse hooks in my application using following call
g_MouseHook = SetWindowsHookEx(WH_MOUSE_LL, MouseProc , hInstance, 0);
The mouse procedure is as follows
extern "C" _declspec(dllexport) LRESULT CALLBACK MouseProc (int nCode, WPARAM wParam, LPARAM lParam)
The MouseProc is calling successfully when current active desktop is "default".
When i switch the desktop to some other desktop, the MouseProc is not calling.
Can anyone tell me reason for this and also solution.
sharda
|
|
|
|
|
From the documentation for SetWindowsHookEx:
dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.
This doesn't actually cure your problem, but hopefully it reassures you that you haven't made a daft mistake.
Iain.
|
|
|
|
|
thanks Iain,
Actually i tried with both the options like
g_MouseHook = SetWindowsHookEx(WH_MOUSE_LL, MouseProc , NULL,0);
and
g_MouseHook = SetWindowsHookEx(WH_MOUSE, MouseProc , NULL,GetCurrentThreadID());
Still in both the cases MouseProc is not called.
|
|
|
|
|
Hi everybody,
in my MDI Application under XP i Lock the MainFrame via LockWindowUpdate if a new Frame will be build and Unlock it if
all creation and initialisations are over.
So the user don't sees that the frame,view and all controls are created one by one (which seems ugly)
For XP this technique works great. But under Vista it don't work.
Creating a new Frame with a View and a TabControl draws several frames, slides it, etc
So the user sees all the creation and draw procedure
Is there a special technique to prevent this under Vista?
Big thanks for answers
|
|
|
|
|
I need some help about the user I/O run-time. Please, help with API or sample code or class.. I have been working on the Win32 CheckMarked platform..
modified 13-Mar-13 5:59am.
|
|
|
|
|
Hakan D wrote: I some need help about user I/O run-time.
Could you please detail your request?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
|
Don't you like cin , do you?
Or have I missed what is your difficulty about?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
|
Hakan D wrote: I dunno, i am not a shameless thief!..
I'm happy about, but it has nothing to do with my question, has it?
Hakan D wrote: I AM NOT BRIGAND, I AM NOT CLAIMING THE BELONG TO TO OTHERS TO THE THING. I'M NOT A MONKEY SO THAT THE BOTHER OTHER LIFE. I HAVE NOT GOT A JOB SUCH LIKE.
Hey man, I'm not a physician...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Someone should go and fetch his dried-frog-pills...
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all. Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
I'm no expert on using the console stuff, but can't you do...
cin >> m_pUser[0] >> m_pUser [1];
etc?
As for your subject... I/O can mean many things. Mouse messages, serial ports, network programming...
Iain.
|
|
|
|
|
|