I was wondering how many people know about structured exception handling...I might be giving the article I wrote on the topic to Gamedev.net and I was interested in how many people actually knew what it was. Cheers.

ummmmm what?

btw I have no clue wtf this is =)


Great Milenko

Words Of Wisdom:
"Never Stick A Pretzel In Your Butt It Might Break Off In There."

http://www.crosswinds.net/~milenko
http://www.crosswinds.net/~pirotech

I know about it

I can''t say I''m using it, since I''m all for c++. But c/windows users might benefit from it? If I remember correctly, there are api-functions or mfc classes (?) that map seh to c++ exceptions, you might want to say a bit about those too.

SEH is only good for pure C in windows.. you cannot use classes.. I suggest dropping SEH for C++ exception handling (I believe the MSDN recommends this too), which is type safe rather than an integer comparision..

The map function is _set_se_translator

Actually, you can't easily catch hard exceptions with C++ EH (unless you use set_se_translator). Moreover, SEH is used to implement C++ EH on MSVC++ anyway, so C++ EH adds unnecessary overhead that may be avoided by using pure SEH, which carries very little overhead on its own - otherwise MS wouldn't use it to implement most of Windows' fail-safe, robust API. The setup of SEH is also more flexible. Moreover, if you use SEH correctly in C++, you don't need to worry about destructors not being called, and if you do the compiler will warn you about it. And what about termination handling? Plus, it is my belief that EXCEPTION_CONTINUE_EXECUTION is a major benefit to both C and C++ programmers.

Edited by - GayleSaver on July 4, 2000 7:24:40 PM

quote: Original post by Void

which is type safe rather than an integer comparision..

I think the type safety adds overhead, and is a limited way of filtering exceptions. Moreover, re-throwing exceptions is pretty slow. As far integer comparisons go, most people do not know that RaiseException can take arguments of any type, and although the arguments may be DWORDs, with careful coding that should be sufficient. Exception codes are a good way to implement exceptions wihtout much overhead. Hast thou forgotten "This program hath caused an illegal operation..."? That''s UnhandledExceptionFilter. MSDN is not the information source Microsoft would like it to be. This is probably caused by lack of communication between writers of the various parts of the library. Look in the Platform SDK portion, because those people are responsible for the information pertaining to SEH in general. Alas, the MSC++ team seem to have a knack for over-advertising C++ over everything else sometimes.

At work, we''re building a webbased applications on java, so I have to know what SEH is whether I want to or not

In java I use it A LOT. In C++(my own projects), I never really use it, because SEH involves a rather big overhead. It''s not that big, but I prefer to avoid it, so I don''t use SEH.

quote: Original post by GayleSaver

Moreover, if you use SEH correctly in C++, you don''t need to worry about destructors not being called, and if you do the compiler will warn you about it.

I must be missing something here but I cannot get SEH to work with classes. I get an warning about non standard extension and a compiler error about "Cannot use __try in functions that require object unwinding"

This is the small console test code

    #include <windows.h>#include <iostream.h>class Cc      // dummy class{public:	Cc()	{};	~Cc()	{};};void main(){	__try	{            Cc c;	}	__finally	{           cout << "Finally" << endl;	}	return;}    

I can get rid of the error if I disable C++ exception handling in the settings but the warning is still there. I would like to use SEH too if I could set it correctly..

..

I think your problem there with the _finally is the destructor issue. I believe that it is remiss of MS to prohibit use of SEH in C++. When I said "correct usage", I was referring to dynamic objects. Since most routines that use termination handlers will probably be geared to accomplish some task in a top-down manner, you can simply declare dynamic objects with new and clean them up in the termination handler using delete. I don''t believe that''s any harder than using CreateFile and CloseHandle pairs, though it does complicate things a little bit.

Damn, I always do that!

that was my post.