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.