[ros-dev] Error handling

[Phillip Susi]

ea wrote:
  > Does this baroque solution based on the "Think positive!" motto satisfy
> you? :)
> 
> Emanuele
> 
> 
> ------------------------------------------------------------------------
> 
> #include <all_inclusive.h>
> 
> #define CLEANUP_DEFINE  DWORD __FUNCTION__##__cleanup_mask = 0
> #define CLEANUP_SET(f)  __FUNCTION__##__cleanup_mask != (m)
> #define CLEANUP_DO(m,f) if (__FUNCTION__##__cleanup_mask & (m)) (f)
> #define CLEANUP_BIT(b) (1<<(b))
> 
<snip>


I don't think that works either.  The main reason is what is cleanupXXX? 
An external function?  It can't be.  Also it is not very readable at 
all, and you end up with a half dozen macros you have to call for each 
NtXXX() you call, and you get another indent level for each NtXXX() so 
you very quickly will be indented off the screen.



Steven Edwards wrote:
> We have a macro based SEH implementation we are using in ReactOS called PSEH for Portable SEH.
> Hyperion wrote it and it seems to work with almost ever compiler thrown at it. It is not syntax
> compatible with MS-SEH but some people have been working to develop p(retty)pseh which should be.
> Look in reactos/lib/pseh and grep the source tree. Its used in ntoskrnl, win32k, afd?, and others.
> 
> Thanks
> Steven

The problem with that is that none of the NtXXX() functions use SEH or 
PSEH, so you would have to write a wrapper library around them to 
convert the return codes into exceptions before you could take advantage 
of (P)SEH in the calling code.  That seems like a lot of work.  I was 
toying with the idea though of implementing a set of parallel apis next 
to the Zw and Nt functions.  They could be called EhXXX for instance and 
would be called via a new EH aware system call interface.  The EH system 
call interface could wrap the underlying non EH functions and make them 
EH enabled, or directly call any kernel functions that are EH aware. 
The normal system call interface would directly call non EH system 
calls, and wrap and translate the EH system calls.  It's something neat 
to think about, but I don't think it will ever happen.  I just don't see 
why MS invented SEH then didn't bother to use it.  Would be real nice if 
they had just made all the kernel APIs SEH enabled in the first place.