On Fri, Jul 06, 2007 at 03:03:41AM +0100, Pedro Alves wrote:
> Kevin O'Connor wrote:
> >Earlier on, I tried to use the same __try/__except syntax that msdn
> >documents. However, I gave up on it - it was too complicated and not
> >useful for me. In particular, implementing __finally would be
> >painful.
> >
>
> But what is life without pain? Oh well, it gets hidden under some
> macros, so why not? :)
>
> Checkout the attached. Not pretty and easy to follow, but it works, and
> it allows stuff like:
LOL. I'm not sure if I'm impressed or in shock. :-)
> >I still don't know why I can't leave the exception handler with
> >EXCEPTION_CONTINUE_EXECUTION..
>
> Somewhat my fault for hinting wrongly. You should return with
> ExceptionContinueExecution which comes from the following enum:
Thanks - that fixed my handler. Note that you had two places in your
code where you still used the incorrect codes.
> struct eh_data {
> jmp_buf env;
> __seh_filter filter;
> };
This should probably include a "struct eh_data *old_handler", so that
nested try blocks work.
I put this in my code at:
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/haret/include/exceptions.h
http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/haret/src/wince/exceptions.cpp
> #define __TRY \
> do { \
[...]
A couple of comments:
1 - the generated assembly under -O doesn't look too bad.
2 - you call setjmp after start_ehandling. It would be better to
arrange for setjmp to always occur before registering the handler.
(To guard against exceptions occurring before setjmp.)
3 - you call end_ehandling on the exception path in normal code. I
would think calling end_ehandling in the exception handler is more
appropriate - if the filter func raises an exception itself..
4 - I don't think your __finally is correct. Should an exception be
raised in a __try / __finally block, the finally clause should be
run and then the exception should be re-raised. (The macro should
probably take a func like __except_filt - just have it always
return EXCEPTION_CONTINUE_SEARCH.)
5 - You know the msdn docs say you can goto out of a __try block. :-)
> EXCEPTION_DISPOSITION
> eh_handler(struct _EXCEPTION_RECORD *ExceptionRecord,
> void *EstablisherFrame UNUSED,
> struct _CONTEXT *ContextRecord,
> struct _DISPATCHER_CONTEXT *DispatcherContext UNUSED)
> {
> struct eh_data *d = TlsGetValue(handler_tls);
>
>
> if (d == NULL)
> /* Unexpected, perhaps there is another handler installed. */
> return EXCEPTION_CONTINUE_SEARCH;
Hrmm. Will this work? If you continue the search, will it know how
to unwind the stack to find the calling function? That is, we are
hacking the pdata stuff, so I'm not sure a continue search is valid.
It can, of course, check for nested scopes within the calling program
though.
-Kevin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
