On Wed, 19 Apr 2000, Steve Hay wrote:
> > Sounds like a difference in the way CGI scripts and mod_perl buffer. I
> > fyou really want CGI::Carp to work, you need to make sure you don't send
> > any output before it gets called. Maybe you have PerlSendHeader on?
>
> I did have PerlSendHeader On: turning it off causes a DOS Prompt to pop up
> briefly, the die() message still goes to error.log and no output appears in
> the browser at all!
I've never used mod_perl on Windows, so I don't know what causes the DOS
prompt. Keep PerlSendHeader On, but suppress your output until the script
has completed (i.e. collect it in a scalar and then print it all at once).
CGI::Carp can't help you if you've already sent a bunch of stuff to the
browser. You don't have this problem with mod_cgi because it buffers
everything until the script finishes.
> > CGI::Carp can't catch compile errors.
>
> Oh. The CGI::Carp manpage says (regarding the use of "set_message()" to
> control the output message): "In order to correctly intercept compile-time
> errors, you should call set_message() from within a BEGIN{} block. ", which
> suggests it does catch compile errors? I've tried both with "BEGIN
> {set_message('...')}" and without a set_message() at all, but to no avail.
My mistake. CGI::Carp doesn't catch compile errors inside an eval block,
which is where you are when compiling under Apache::Registry. You could
work around this by commenting out the first line of the die() subroutine
where it checks to see if it's in an eval, but that's pretty lame and
makes CGI::Carp incompatible with use of eval blocks. I don't use
Apache::Registry or CGI::Carp, so I'm not very motivated to find a better
fix. You could contact the author.
- Perrin
