Possible problems with SSE usage.

[dedndave]

well - i have just seen several C examples where the exception was the rule (slap me if that's a bad pun - lol)
i am kind of an old-school guy, i know
but, i have always tried to write code so that errors don't happen to begin with
in the case of peripherals or some other hardware, of course, you can't always do that
but, generally, i try to test for and force correction of an error before allowing it to occur

here is a simple example:
i want to use the DIV instruction
prior to using it, i insure the dividend is within range and the divisor is non-zero
in most cases, the logic of the code is such that these error conditions cannot occur
if they do occur, i allow the user to alter input parameters to fix the problem or whatever steps are appropriate
if divide-by-zero does occur in my program, it indicates that i have a bug in my code
i don't use the exception handler to catch the mistakes - lol

now - that isn't very modern, perhaps
but, when i see exception handlers used that way, the term that comes to mind is "lazy coder"
i suppose there are many modern cases where my perception is off-base   :P

[asmfan]

Why you need to use SEH if nobody except you won't process raised exceptions?
YOur app is anyway SEHed my Windows before it starts. UnhandledExceptionFilter etc.
If it designed to crash it will crash anyway with self-made SEH or without and with system-made SEH.
Bad design and unhandled SEH is the reason of known result.
Windows is smart enough to handle properly such designed apps. So either you use SEH or you don't Windows anyway will terminate your/someone's/ buggy app.

[MichaelW]

Computers are getting so fast now that a few more clocks to handle SEH isn't detrimental like back in the day.

A "few" more clocks? In my test it took ~11000 more clocks just to bypass a divide by zero and continue execution.

[ecube]

Computers are getting so fast now that a few more clocks to handle SEH isn't detrimental like back in the day.

A "few" more clocks? In my test it took ~11000 more clocks just to bypass a divide by zero and continue execution.

If you're just writing hobby code that you're not going to use in any program of importance then you don't have to use SEH. When you write programs that many users use however, and your lack of SEH  puts the users system at risk, like the countless apps i've seen on the "exploits" lists, then that's a problem.

[jj2007]

A "few" more clocks? In my test it took ~11000 more clocks just to bypass a divide by zero and continue execution.

IMHO the extra clocks are not the problem. The divide by zero is result of bad design, so let it crash properly, with a slap in the coder's face. As Dave put it, "lazy coders" use the handler to avoid reflecting on proper design. I wish lstrcpy would crash instead of silently "handling" an access violation.

[ecube]

Microsoft already gets enough heat from skiddies exploiting some of their API functions, inturn exploiting users systems, that's in part why they created managed code and the safe API. I think lstrcpy not crashing is a good thing, all errors should be handled gracefully, because keep in mind the general users can barely check their email much less know about programming etc...they don't want to see a program crash...it scares them.

[hutch--]

Rockoon is right here, exception handling is for code that must deal with events that cannot be predicted at compile/assembly time, hardware, internet connections and the like, if something is not physically available then you must have a way to deal with the lack of response but outside of those circumstances you should write code that does not have faults in it for its target market. Better to write suicide code that explodes in you face with an error than to have undebuggable junk that hides the problem.

[MichaelW]

IMHO the extra clocks are not the problem. The divide by zero is result of bad design, so let it crash properly, with a slap in the coder's face. As Dave put it, "lazy coders" use the handler to avoid reflecting on proper design. I wish lstrcpy would crash instead of silently "handling" an access violation.

I agree. My point was that the few more clocks justification is not valid.

[ecube]

IMHO the extra clocks are not the problem. The divide by zero is result of bad design, so let it crash properly, with a slap in the coder's face. As Dave put it, "lazy coders" use the handler to avoid reflecting on proper design. I wish lstrcpy would crash instead of silently "handling" an access violation.

I agree. My point was that the few more clocks justification is not valid.

The justifications have already been pointed out. but let me reiterate and also clarify something for you, the clock cycles you posted does NOT increase incrementally, that is, you can write a great deal of addition code in side of your session handler for example and it wouldn't be astronomical in cycles just because it's in a session handle, it's just the inital setup that takes the cycles. Also I recommend VEH over SEH as it's a lot more intelligent and I bet it's faster too.

As far as its use, i'm aware a lot of you are seasoned programmers, but this is definitely not the early 90's anymore, a lot has changed, including the programmers responsibility to write safe/reliable code, not just in terms of your program using it, but from outside influences as I mentioned earlier. Also SEH,VEH etc... set to log function/code crashes is a very nice/fast way to narrow down bugs in your program, much faster than debugging. Especially on x64 where they're aren't a lot of good debuggers out yet. And thinking in the future, how great would it be for a user to be able to run your program on windows 13 that you wrote for windows xp, and have a log generated of the apis/functions crashing so that you can easily write a fix :)

[oex]

:lol By Windows 13 my computer will be fixing it's own damn bugs

[asmfan]

Seh is only needed when dealing with smth. system-wide or global. That's shared among all processes - system settings, events as said, etc. which surely must be processed at app termination - cleanup time. The rest can be handled by checking return values GetLastError or by separate thread & synchronization (wait/until) - the weirdest nonblocking case.

[MichaelW]

The justifications have already been pointed out. but let me reiterate and also clarify something for you, the clock cycles you posted does NOT increase incrementally, that is, you can write a great deal of addition code in side of your session handler for example and it wouldn't be astronomical in cycles just because it's in a session handle, it's just the inital setup that takes the cycles.

The cycles I posted were for handling the exception. My test consumed ~3000 cycles if there was no exception, or ~14000 cycles if there was an exception.

[KeepingRealBusy]

Jez, guys! I'm sorry I raised such a firestorm. I was just trying to insure that I wouldn't walk off of a VIrtualAlloc buffer using SSE loads.

Dave.

[Rockoon]

If your code is *expecting* an exception, there is something wrong.
...
Rare events are not part of normal flow control.

Normally I would strongly agree - but what if the "good" checks cost so much more time than letting it crash, in a controlled way, into an "exception"? Guard pages do that all the time - have a look at the page faults column in Task Manager...

If the "good" checks cost more than the exception, then its a very rare event. You do know how costly exceptions are, right? :) First it goes to the OS's exception handler, then possibly it gets offloaded to yours, and then maybe back to the OS again for the ones still unhandled.

As far as the vast majority of page faults listed in task manager, they are being handled by the OS's virtual memory subsystem. I believe only two scenarios encompass the entire count:

memory that was swapped out
memory mapped files

Neither of these is handled by your application, so actually falls under my other observation: not being handled by the local procedure

If there are other faults included in the count, I'm all ears. I do not believe that the faults that your program catches are included in the count, but meh..

[Rockoon]

Ah, now here is the rub.

On the one hand we have code that is going to overshoot its buffer on purpose, and then from time to time it is going to just catch an exception if one is raised because it not only overshot the buffer, it also overshot the contiguous memory pages the buffer resides in.

On the other we have code that will divide by zero from time to time, where the programmer is going to just catch the exception if one is raised, and then execute default-value semantics, error out, or whatever.

One of these is not like the other. In the buffer case, not only are we overshooting the buffer on purpose, but sometimes we also overshoot the process space too? Wow. Just wow. In the divide by zero case, its accidental or incidental, and not on purpose.

One area where I normally just want to swallow exceptions is fsqrt. Luckily the FPU lets us do just that.