Adam Prime wrote:
This was news to me, so i went to the docs. According to them, you have
to explicitly enable this behavior. see:
http://perl.apache.org/docs/2.0/api/Apache2/Log.html#C_Apache2__Const__LOG_TOCLIENT_
Is that still accurate?
I don't know about mod_perl2, but I didn't hav
Michael Peters wrote:
You don't even need to use a __DIE__ handler. mod_perl will place any
runtime errors into $r->notes('error-notes'). I don't like my errors
going to the browser (only really works if your content is HTML anyway)
but for the email I usually use an Apache cleanup handler. T
Perrin Harkins wrote:
I'm not sure if that's accurate or not, but setting a $SIG{__DIE__}
handler should work fine.
You don't even need to use a __DIE__ handler. mod_perl will place any runtime
errors into $r->notes('error-notes'). I don't like my errors going to the
browser (only really wor
On Mon, 2009-03-02 at 10:20 -0500, Perrin Harkins wrote:
> On Mon, Mar 2, 2009 at 9:54 AM, Matthew Lenz wrote:
> > According to the docs CGI::Carp doesn't function properly with
> > fatalToBrowser under mod_perl 2.
>
> I'm not sure if that's accurate or not, but setting a $SIG{__DIE__}
> handler
On Mon, Mar 2, 2009 at 9:54 AM, Matthew Lenz wrote:
> According to the docs CGI::Carp doesn't function properly with
> fatalToBrowser under mod_perl 2.
I'm not sure if that's accurate or not, but setting a $SIG{__DIE__}
handler should work fine. BTW, I assume you mean stacktrace, not
backtrace,
As I've mentioned in previous posts, I'm migrating from an older
environment to a new environment with mod_perl 2.
With mod_perl 1.x we had VERY OLD customised version of CGI::Carp (with
fatalsToBrowser) printing an error to the browser AND sending an email
with backtrace and environment informati
