Re: [WWdevel] summary of $SIG{__DIE__} and $SIG{__WARN__} usage in Translator.pm

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok,

I've implemented the changes to Translator.pm as discussed in this  
thread. Here's the commit message:

> Fix use of $SIG{__WARN__} and $SIG{__DIE__}.
>
> * Each change to $SIG{__WARN__} and $SIG{__DIE__} is now dynamically
> scoped with "local", rather than changing globally and then  
> restoring at
> the end of the block.
>
> * The special value "DEFAULT" is used instead of sub {CORE::die 
> (@_)} or
> sub {CORE::warn(@_)} when preparing to eval STRING code.
>
> * Where $SIG{__WARN__} and $SIG{__DIE__} are overridden to do
> preprocessing with PG_errorMessage, the previously installed handlers
> will be called instead of the built-in warn or die functions after
> preprocessing occurs. (For example, the warn and die handlers  
> defined in
> Apache::WeBWorK or the warn handler defined in WeBWorK::PG will be
> called.)
>
> * The behavior in process_answers is modified so that the custom
> handlers are installed once before the answer evaluation loop. This
> causes them to be in effect during the setup/teardown code, but I  
> don't
> think this will be a problem.

Davide -- can you take a look at the changes I made to error handling  
in process_answers? Mike tried pulling the handler out of the for  
loop and it worked for him, so I committed that. Do you see any  
problem with that? I also made %errorTable a lexical instead of  
dynamically scoped. It's not used anywhere else but inside that  
scope, so I think it'll be fine.

I think I understand how %errorTable functions. Am I correct that it  
stores the output of PG_errorMessage (so that it doesn't step on the  
toes of answer evaluators that throw and then catch their own  
exceptions), and then if an exception goes uncaught (inside the  
answer evaluator), it is caught in process_answers and the full error  
message is retrieved from the table?

If so, I don't think we need a hash at all, since there will only be  
one uncaught exception per answer evaluated, and that will be the  
most recently thrown exception. So, it seems to me that it would  
suffice to just store the most recent error message in a scalar since  
that's the only one we're going to report on.

This whole mechanism seems dodgy to me, but I can't think of any  
better way to do it. We need to be high up on the stack than the code  
that caused the exception in order to generate a stack trace, and we  
have to wait and see if the exception gets caught by someone else  
before we commit to reporting the trace. It seems to me that this is  
the only way to go.

Please let me know if I'm thinking about this properly. :)
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC6omt14CQX+2WvVgRAnNOAKC/BEdf7fOtlMkydVR2e2u4G34/fgCeNK3D
ozaNL+yNHcx73jBKI6GI498=
=JmMS
-----END PGP SIGNATURE-----