(chromatic) Re: How may I know why it died?

The CGI::Carp module might come in handy here. Put the following near the top to trap die exceptions: use CGI::Carp qw(fatalsToBrowser); I wouldn't run this in production code, as it could give out information a malicious cracker might be able to exploit.

Update: Okay, it might not. Win some, lose others.

Comment on (chromatic) Re: How may I know why it died? Download Code

Replies are listed 'Best First'.
RE: Re: How may I know why it died? by Abigail (Deacon) on Jul 15, 2000 at 11:08 UTC
The CGI::Carp module might come in handy here. I don't think so. `CGI::Carp` masks `die`, `warn` and friends. And while it has a method to redirect `STDERR` to a file, it doesn't hand you the errors of spawned sub processes. However, the standard distribution of Perl comes with `IPC::Open3`, which allows you to give it a filehandle that will be connected to the spawned processes' `stderr`. One can than just read from this handle and capture any errors. Note that you might have to use `IO::Select` to avoid blocking problems. Read the man page of `IPC::Open3`. -- Abigail	[reply]

Replies are listed 'Best First'.

RE: Re: How may I know why it died?
by Abigail (Deacon) on Jul 15, 2000 at 11:08 UTC

The CGI::Carp module might come in handy here.

I don't think so. CGI::Carp masks die, warn and friends. And while it has a method to redirect STDERR to a file, it doesn't hand you the errors of spawned sub processes.

However, the standard distribution of Perl comes with IPC::Open3, which allows you to give it a filehandle that will be connected to the spawned processes' stderr. One can than just read from this handle and capture any errors. Note that you might have to use IO::Select to avoid blocking problems. Read the man page of IPC::Open3.

-- Abigail

[reply]