 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / December 2004synchronous vs. asynchronous exception model
Can someone explaing the difference between these exception models regarding the structured exception handling? The documentation is not clear. Some code would actually help. Thx > Can someone explaing the difference between these exception models > regarding the structured exception handling? The documentation is > not clear. Some code would actually help. The difference lies in assumptions the compiler makes about where exceptions can be thrown. Under the synchronous model, only throw statements can result in an exception being thrown. Under the asynchronous model, any instruciton can result in an exception being thrown. As a result, under the synchronous model, the compiler can leave out exception handling code in areas where it can prove that no exception can be thrown (due to the lack of throw statements), while under the async model, all of the exception handling machinery is required all the time. If you're writing C++ code that needs to handle native (Win32 Structured) exceptions, you should be compiling with /EHa. If you don't, there may be cases where objects with automatic storage (i.e. stack based) do not have their destructors called when a native exception is raised. -cd And if you are compiling parts of your call tree with /clr you need to use /EHa as well since the CLR uses SEH exceptions as its underlying mechanism. Ronald Laeremans Visual C++ team >> Can someone explaing the difference between these exception models >> regarding the structured exception handling? The documentation is [quoted text clipped - 17 lines] > > -cd > And if you are compiling parts of your call tree with /clr you need to use > /EHa as well since the CLR uses SEH exceptions as its underlying mechanism. I find this rather hard to swallow. When creating a Managed C++ project, the IDE will automatically set /clr and /EHsc. Does this mean that you get incorrect compiler settings by default? And why do managed exceptions seem to work in my application?  SignatureGerhard Menzl #dogma int main () Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". >> And if you are compiling parts of your call tree with /clr you need to >> use /EHa as well since the CLR uses SEH exceptions as its underlying [quoted text clipped - 4 lines] > incorrect compiler settings by default? And why do managed exceptions seem > to work in my application? I also didn't know about this, and it seems a rather dangerous omission. I don't know of any problems we've had NOT using /EHa, however. There also doesn't appear to be any option in the IDE to enable /EHa - which means that the development team either didn't have a lot of problems not using it, or added it programmatically to the command line but didn't add it to the IDE for whatever reason? Steve >>> And if you are compiling parts of your call tree with /clr you need >>> to use /EHa as well since the CLR uses SEH exceptions as its [quoted text clipped - 11 lines] > have a lot of problems not using it, or added it programmatically to > the command line but didn't add it to the IDE for whatever reason? I believe you have to add it explicitly to the command line in the IDE. This is fixed in Whidbey - /EHa is added authomatically, and attempting to compile with /clr /EHs produces an error. See my other reply (to Gerhard Menzl) for why you've probably never noticed anything not working. -cd >>>> And if you are compiling parts of your call tree with /clr you need >>>> to use /EHa as well since the CLR uses SEH exceptions as its [quoted text clipped - 18 lines] > See my other reply (to Gerhard Menzl) for why you've probably never > noticed anything not working. Have done, and yes, it probably does explain it. Presumably none of the MS engineers came across it either (or they're not telling). Good to know (as per usual) that "it's fixed in the next version" :-) Thanks, Steve >> And if you are compiling parts of your call tree with /clr you need >> to use /EHa as well since the CLR uses SEH exceptions as its [quoted text clipped - 5 lines] > managed > exceptions seem to work in my application? That's what it means, yes - MC++ projects created by VC++ 2003 don't handle exceptions properly. Unless you produce a construct in which an unmanaged object exists in a stack frame above the point at which a managed exception is raised and below the frame where the managed exception is caught and the exception frame in which that unmanaged obect was optimized away, you'll never see a problem. So it's a pretty special case that doesn't work. If your calling pattern is always managed -> native and never vice-versa, I don't think you'd ever see a problem. -cd > Unless you produce a construct in which an unmanaged object exists in > a stack frame above the point at which a managed exception is raised > and below the frame where the managed exception is caught and the > exception frame in which that unmanaged obect was optimized away, ...and the destructor of the native object does something important enough that you'd notice if it wasn't called... > you'll never see a problem. -cd > That's what it means, yes - MC++ projects created by VC++ 2003 don't handle > exceptions properly. [quoted text clipped - 7 lines] > always managed -> native and never vice-versa, I don't think you'd ever see > a problem. Hm, I have managed objects that contain Standard Library containers of (gcrooted) managed objects that may throw. And our release-or-perish deadline is a mere fortnight away. Words like "creeps" or "heebie-jeebies" come to mind ... SignatureGerhard Menzl #dogma int main () Humans may reply by replacing the obviously faked part of my e-mail address with "kapsch". Well, it seems like it's bad both ways, isn't it. On one hand, the assumption that only throw statements will result in an exception is ridiculous. I need to write C++ code to cope with SEH (e.g., accessing invalid pointers, etc.). However, having objects with automatic storage undestroyed poses yet another risk. Does translating the SEH exceptions to C++ exceptions help in any way? I just read an article on The Code Project on replacing the exceptions, but at the end it also recommends using a workaround or the asynchronous model. Thx > Well, it seems like it's bad both ways, isn't it. > [quoted text clipped - 4 lines] > pointers, etc.). However, having objects with automatic storage > undestroyed poses yet another risk. If you compile with /EHa there is no such risk. > Does translating the SEH exceptions to C++ exceptions help in any > way? I just read an article on The Code Project on replacing the > exceptions, but at the end it also recommends using a workaround or > the asynchronous model. To translate exceptions to C++ exceptions you need to compile with /EHa. Under VC7{.1}, you can go through the motions of converting SE's to C++ exceptions (__set_se_handler, etc), but in practice it won't work. Anywhere the compiler optimized out the exception handling machinery, you translation will just as effectively have been optimized out. A couple things to be aware of when translating exceptions: First, you need to call __set_se_handler separately in each thread. Second, there's only one handler per thread, so if some other library has already done it, you'll wipe out their handler. Finally, the translator is called each time a catch() block is evaluated and an SE is being processed (it's called by the exception filter routine, in Win32 SEH terms). If you have deeply nested try/catch structures, you may translate a single excepiton many times before it's handled (or not). Look for articles on Matt Peitrek and a series by Bobby Schmidt on MSDN for lots of details into how exception handling works if you need more info. IMO, there's no downside to /EHa except for slightly slower code in some cases. If you're serious about catching and dealing with structured exceptions, or interacting with code that uses structured exceptions, you must use /EHa. As Ronald pointed out, any interaction with the CLR requires /EHa. In fact, in VC++ 2005 this is enforced by the compiler - adding /clr implicitly add /EHa and will cause an error if you try to use /EHs. -cd Thx. Very helpful information--thus the MVP title, eh? > Thx. Very helpful information--thus the MVP title, eh? I always thought you had to climb tall mountains and meditate with wizened gurus to get the MVPs.. that's my illusions shattered.. Steve >> Thx. Very helpful information--thus the MVP title, eh? > > I always thought you had to climb tall mountains and meditate with > wizened gurus to get the MVPs.. that's my illusions shattered.. The mountain-climbing does help... ;-) -cd replace __set_se_handler with _set_se_translator throughout the posting above. -cd Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.