I would say that the presumption in user mode is that you can actually see
the code that raised the exception and can, at the appropriate place after
the RaiseException, put code that “fixes” the problem so you can tey
again. But when some low-level function in the kernel finally raises an
exception, it almost certainly has no recovery code following the
RaiseException, so continuing at that point makes no sense.
Back in the 1970s, when we were beginning to deal with the complexity of
what was then called “programming in the large”, several important ideas
emerged. One was the [in]famous “goto” controversy; sadly, far too much
Microsoft code uses gotos when there are cleaner ways to deal with the
problem. Then there was the “global variables considered harmful” paper,
which resulted in concepts like keeping state inside objects. One that
never quite made it was the consequences of using exceptions as control
structures. It is hard enough to comprehend a piece of code, but when
something that code calls can throw an exception, you usually end up with
an unmaintainable mess. Not because exceptions are harmful, per se, but
because poor use of them and poor documentation can result in really nasty
surprises.
For a period of ten years I worked in languages that had exceptions as a
formal syntactic structure in the language. Of all the languages I worked
in, the one with continuable exceptions, which, alas, many programers
thought was “cool”, resulted in the most incomprehensible,
least-cost-effective, totally unmaintainable messes it has ever been my
misfortune to have to debug. Usually, the first thing I did was find all
the places where that language’s EXCEPTION_CONTINUE_EXECUTION occurred,
and carefully rip out all that code and the “recovery” code, and that was
often faster than finding the actual bug (it did take me a couple years to
get management to recognize this was the only valid approach).
Have you ever heard of the COMEFROM statement? Take a language like
BASIC, with line numbers. Remove the GOTO from the language because We
Know Gotos Are Bad. Instead, add a COMEFROM statement. COMEFROM 500
meant that after executing line 500, control would transfer to the
COMEFROM statement. We would have discussions that led to “the computed
COMEFROM”, how to handle multiple COMEFROMs from the same line, and other
fine points of semantics. The best discussions happened only after the
majority of participants had four or five beers.
Recoverable exceptions make programs written using COMEFROM look like
models of clear and lucid programming. Been there, done that. The only
people who think recoverable exceptions make sense are those who never had
to write, debug, and/or maintain such programs
joe
Hi
" Presumably, if a driver were able to resolve the cause of the exception
it might be possible to use EXCEPTION_CONTINUE_EXECUTION, but we have yet
to see a case where this is done successfully within a driver. Perhaps
one of our loyal readers would like to prove us wrong by sending in a
sample!"
http://www.osronline.com/article.cfm?id=58
Also, Programming the Microsoft Windows Driver Model book says:
“You should not return EXCEPTION_CONTINUE_EXECUTION in kernel mode because
you have no way to alter the conditions that caused the exception in order
to allow a retry to occur”
Why is there a way to alter the conditions in user-mode but not in
kernel-mode?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer