so you should be able to write such a handler...

I love your faith in my abilities! I'm not so sure...but, you are right, the CGI::Carp source doesn't look especially complex.

Perhaps there is another big step in the stairway of learning directly in front of me.

Just omitting CGI::Carp and just using plain old Carp should do the trick. Carp behaves nicely and writes all errors to STDERR, where they belong. The web server collects STDERR output and writes that to its error log. Problem solved, even when multiple CGIs are running concurrently (which might create nasty races when trying to write to a common log file at the CGI level). That also works when your CGI has a really bad day and just crashes before Carp or CGI::Carp can do their work.

The only remaining problem might be the hoster: Some really cheap hosters prevent you from reading your server's error log. That really sucks, and cannot be solved completely at the application (CGI) layer. If that is the case, consider changing the hoster or upgrading to a contract with access to the error log.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Just omitting CGI::Carp and just using plain old Carp should do the trick

It's late here so a quick test before I head to bed...
I've changed from CGI::Carp to Carp in the script that gives the 500 error as suggested. Of course it makes no difference to the way the script behaves. But also, it doesn't write anything to the cPanel error log.

The only remaining problem might be the hoster: Some really cheap hosters prevent you from reading your server's error log

I've never been entirely sure what the cPanel error log actually is so I have dived into the documentation to find out. Its says "The interface includes entries in the /usr/local/apache/logs/suexec_log file and the /usr/local/apache/logs/error_log file"

Not knowing a great deal about the inner workings of Apache and cPanel, it looks to me like the latter will be the right error log file where these sorts of errors should be written. Certainly lots of "File does not exist" errors get written there along with a few Perl warnings and the odd MariaDB error.

The script I am calling gets listed in the suEXEC log but the one that it calls (the one with the error) does not.

Since it's not https-related, you're probably back to wanting a fatalsToFile equivalent

It turns out that it is https-related...

There were two red herrings.
Firstly the .htaccess uses a 301 redirect that was being cached and also the getstore method of LWP::Simple is not doing what I expected.

my $availability;
my $response = LWP::Simple::getstore("http://$ENV{'HTTP_HOST'}/cgi-bin
+/booking.pl?command=check&st=$data{'st'}&ed=$data{'ed'}&force=$data{'
+force'}", $availability);
print "->$availability<-\n";
print "$response\n";
[download]

So, now I know that it is an HTTPS issue, I need to find a way to fix it...

Are you sure you're using getstore correctly? Per the LWP::Simple docs:

getstore

my $code = getstore($url, $file)

Gets a document identified by a URL and stores it in the file. The return value is the HTTP response code.

getstore desires a URL and a filename. Your code snippet shows $availability as being undefined.

Are you sure you're using getstore correctly?

No - I had read it as storing the document in a variable, not a file...