Ge van Geldorp wrote:
From: Gunnar
Dalsnes
Phillip Susi wrote:
I'd just like to chime in here with my
opinion. About a year ago I
had the idea of introducing macros for error handling instead of
explicit gotos. We had some discussion on the matter, and I read
several papers on the web, and came to agree that use of
macros that change flow control is anathma. It makes the code
completely unreadable and unmaintainable.
In win32k i use macros for flow control in the NtUser
syscalls (functionally like a try/finally block) where its
very important that some cleanup (release a lock) is always done:
BOOL NtFunc()
{
DECLARE_RETURN(BOOL);
Lock();
if (Stuff) RETURN(FALSE);
....
RETURN(TRUE);
CLEANUP:
Unlock(Stuff);
DPRINT1("NtFunc returned %i\n", _ret_);
END_CLEANUP;
}
And I think these macro's are a perfect example of Phillip's point. I have
no idea how the flow of control is without looking at the macro definitions.
Sure you do, if you try _reeeealy_ hard;-P Ok, those RETURN's set the
_ret_ value and transfer control to the CLEANUP block. END_CLEANUP does
the actual return with the value passed in RETURN. If you fallthru to
the CLEANUP block you will assert so you must RETURN before the CLEANUP
block. The CLEANUP block can be seen as an externel function but for
obvious reasons it needs to be in the function... Hope this helps:-D
For you it's easy, you wrote them, but for the
rest of us it is obfuscating.
I didn't like it when you introduced this stuff in win32k.
The alternative is: do the cleanup at every return, use goto or use
try/finally.
1)Cleanup at every return is madness. Most functions in ros do a large
amount of cleanup at each return and I sometimes spot mistakes where
one/more return misses some cleanup. Those errors are _hard_ to find.
2)Using gotos are much more ugly imo.
3)try/finally could be used if we supported returning from a try block,
thou this is not really recomended either because of unwinding. The
common solution is to goto to the end of the try block, but then we are
back to start.
G.